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SIGnificant Meeting 

Saturday, April 26, 1986, at 3 PM in the suite 

The AI SIG will hold an important organizational meeting prior to the 
1 Dallas symposium at 3 PM in the AI/L&T/UNISIG suite. We will be discussing 
SIGnificant issues at this meeting and may be voting. This is an OPEN 
meeting. You are welcome. If you would like to offer input, but will not 
be able to be in Dallas on Saturday, please contact Terry Shannon 
(newsletter editor), Chris Goddard (membership coordinator), or Cheryl 
Jalbert (chair). 

Thank you for your input. I'll look forward to seeing you in Dallas. 

Cheryl Jalbert 
AISIG Chair 
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Spring is here! Time for the Dallas Symposium. 

What could be more welcome right now than a week of sunshine, the 
excitement of seeing old and making new friends, a stream of sessions that 
will knock your socks off! 

The guys responsible for putting the sessions together for this Symposium 
have done another outstanding job! 

Special "Atta-Boy"s go to Steve Simek for putting the sessions together 
in a logical stream so that, hopefully, your two favorite sessions are not 
scheduled at the same time. In fact, they should go to the entire team for 
an extremely difficult job - well done! If you run into any of the 
Symposium Coordinators at Dallas, let them know their hard work is 
appr ecia t ed. 

At last count, the Business Application SIC has 45 sessions set for 
Dallas. These cover A-Z product information, sessions on MRP and JIT, 
Project Management, and much, much more. Some of these sessions are 
repeats of past popular presentations and some are new for Dallas. Be sure 
to attend the Monday morning Road map Session and make sure your week is 
profitably spen t. 

In addition, the SIC is sponsoring a Pre-Symposium Seminar on Developing 
Large Applications on a VAX. Check this out even if you don't have a VAX. 
Many of the principles outlined are valid for any large application. 

This month's question concerns Symposium and gives all those attending a 
real opportunity to help those who are not. We would like to hear from 
those attending about there exper iences at Dal las. Did you see a session 
that was particularly helpful or informative? Write up a short (or long) 
essay and give us the benefit of your experiences. Maybe about one 
session, maybe about the whole Symposium. By communicating the value of 
Decus Symposium to those not able to attend, you can help them justify 
future at tendance. 

That raises another point. For those attending, how do you get approval 
for funding? Is it easy, hard, tricky? I heard of one System Manager who 
justified it as Manager Maintenance! He said. "We pay for Hardware 
Maintenance, Software Maintenance, so why not Manager Maintenance?" 

Let us hear from you. Anonyminity is guaranteed. 

In addition to Dallas, I would like to spend a moment talking about one 
of my favorite subjects. How can you be sure that quality results come out 
of the systems you design and use? 

As I talk to othe. System Managers, I find that we are all concerned 
about some of the same problems. The software we have is poorly designed, 
hard to modify, un-documented, etc. The people who use the system don't 
read the documentation anyhow, or don't care, or don't pay attention. The 
results are that many times we find ourselves putting out fires that could 
have been prevented. 
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How are you hand I i ng these kinds of problems? What methodologies are 
your using to cure/prevent problems in the future. I think this topic is 
tremendously interesting to most of the members of the SIC. Write your 
solutions down and get them pubI ished. 

Let's create a dialog among the membership. That is after all the whole 
purpose of being a member in the first place, sharing information about how 
to do things better. 

Decus membership should not be a passive thing. Your contributions are 
what make it a strong and vital organization. 

We all look forward to seeing you at Dallas and in the Newsletter. 
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FROM THE SIC CHAIR 

SPRING 1985 DECUS SYMPOSIUM APRIL 28-MAY 2, 1986 
BUSINESS APPLICATIONS HIGHLIGHTS 

The DECUS Dallas Symposium promises to be of great interest to users, 
designers, and managers of application systems for business. The DECUS 
Business Applications SIC is presenting a symposium experience comprised of 
numerous sessions covering such diverse topics as: 

o Conversion of IBM DP Systems to VAX 

o MRP and JIT Considerations for the Small Manufacturer 
o Buying 3rd Party Accounting Software 
o Applications in PBX and Facilities Management 
o In House Typesetting 
o Software Publishing 

o Technologies for Future Small Business Systems 
o Computer Assisted Project Management 
o Performance in the Small Business Environment 
o Designing Multi-National Software Applications 
o Packaged Software and the International Market 
o Government Procurement System Design 
o Electronic Order and Invoice Transmission 
o Simplifying Applications With State Tables 
o Management Concerns in Integrating VAX Applications 
o Application Software for DEC Systems 

and many MORE. 

This, AS WELL AS 


A full complement of sessions covering Digital's A-to-Z Systems Integration 
products. Among the many A-to-Z sessions are: 


o Introduction to A-to-Z 

o How A-to-Z Solves the Application Integration Puzzle 
o A-to-Z/All-In-One Differences 
o A-to-Z in the Business Environment 
o A-to-Z State of the Product Announcement 
o Adding Non A-to-Z Applications to the A-to-Z Environment 
o A-to-Z in an Application Environment 
o A-to-Z Communications 
o A-to-Z Data Management 


and many MORE! 

We would like you to pay particular note to session BA54 which is the 
Business Applications Clinic and Get-Together! This session is an 
informal problem solving clinic and get-together for those of us interested 
in business applications. Visit this session on Wednesday April 30th, at 
5pm in the South 413 room of the Convention Center, and meet fellow Business 
Applications users and DEC Developers, in order to solve problems and 
share experiences. Refreshments will be available. 

This brief survey represents just a portion of the Business Applications 
offerings during the week of the Symposium in Anaheim. Visit us at the 
welcoming reception Sunday night, in our campground at the convention 


center, our suite at the Anatole Hotel, at our sessions, and have a good, 
as well as informative time this April. 

JOIN US 

Monday Morning for the Business Applications Roadmap Session. 

At the Business Application Roadmap, we will highlight sessions throughout 
the week that we feel will be of interest to the business community. 

We will also offer at this session some tips on survival during Symposium 
Week, such as where to eat, where to meet, who's who, and where's our 
suite... 

Let's do some SIGnificant Business in Dallas! See you there! 


STU LEWIS 
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2235 Meyers Avenue • Escondido, CA 92025-1070 l 

(619)745-6006 

Davy Crockett beat Mike Fink in the Mississippi River to New Orleans because 
he took a short cut through a swamp that saved him thirty miles. BASIC 
programmers have short cuts that are called functions. Here are five functions 
that might come in handy. 

The first function is a little number that divides a string at a specified 
character. It uses in string search, a system utility, to find the first 
occurance of the specified string and then splits the whole string into 
two parts - "throwing away" the specified string. 

Parameters: 

X0$ is the string to be split. 

Xl$ is the string at which X0$ will be split. 

Returned: 

FN1$ will be the left part of the string to be split, X0$, before 
the first occurance of Xl$. 

X2$ will be the right part of the string to be split, X0$, after 
the first occurance of Xl$. 

The function: 


DEF* FN1$(X0$,X1$) 

X%,X1%=INSTR(1%,X0$,X1$) 
X%=LEN(X0$)+1% UNLESS X% 
FN1$=LEFT(X0$,X%-1%) 
X2$=RIGHT(X0$,X%+LEN(X1$)) 


]*SPLIT X0$ INTO FN1$ AND X2$ 


The second function is used to convert a string date into a RSTS system date. 
The system date is a integer that is 1000 times (the year - 1970 ) plus 
the Julian date. The returned system date can then be used to perform 
mathmatical functions. 

Parameters: 

X$ is the date in itm-dd-yy, dd-nmm-yy or mrddyy format. 

Returned: 

The date converted to system format. 

There is also a error flag. E% will be zero if the function 
completes successfully, a value indicates that it failed. 


The function: 


FN2_1: 

DEF* FN2%(X$) 

X$=DATE$(0%) IF X$="TODAY" 

X$=LEFT(X$,2%)+"-"+MID(X$,3%,2%)+"-"+RIGHT(X$,5%) & 

IF LEN(X$)=6% UNLESS INSTR(1%,X$,"-") 

X4%=INSTR(1%,X$,"-") 

X5%=INSTR(X4%+1%,X$,"-") 

E%=1% 

FN2%=-1% 

IF X$="00-XXX-00" THEN 
X8%=-1% 

GOTO FN2_2 

END IF 

GOTO FN2_3 IF X4%*X5%=0% 

X6%=VAL(RIGHT(X$,X5%+1%))-70% 

GOTO FN2_3 IF X6%<0% OR X6%>29% 

X6%=X6%*1000% 

X6%=X6%+243% IF INSTR(l%,"SOND",EDIT$(MID(X$,X4%+1%,1%),32%)) 

IF X5%-X4%<4% THEN 

X7%=VAL(LEFT(X$,X4%-1%)) 

GOTO FN2 3 IF X7%<1% OR X7%>12% 

X$=MID(X^,X4%+1%,X5%-X4%) & 

+RIGHT(DATE$((X7%-1%)*31%+1%+X6%),4%) 

X6%=X6%+(X7%-1%)*29% 

END IF 

X$=EDIT$(X$,34%) 

X$="0"+X$ IF INSTR(1%,X$,"-")=2% 

GOTO FN2_2 IF X$=EDIT$(DATE$(X8%),32%) FOR X8%=X6%+1% TO X6%+366 
GOTO FN2_3 

FN2_2: 

E%=0% 

FN2%=X8% 

FN2_3: 

FNEND 

Sometimes you might to know what day of the year it is. The next function 
is a non privileged way to get today's date in system format. 

Parameters: 

None. 

Returned: 

Today's system date. 

The function: 


FN3_1: 

DEF* FN3%=SWAP%(CVT$%(RIGHT(SYS(CHR$(6%) 4CHR$(-3%)),27%))) 

!*N0N-PRIV WAY OF GETTING TODAY'S JULIAN DATE 
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Now that you know what day it is, you might like to add of subtract days. 

This function will allow you to do just that. A positive number will 
add days and a negative number will subtract days. 

Parameters: 

Xl% is the date to be incremented, decremented, in system date format. 
X2% is the number of days to add. 

Returned: 

The resulting day in system format. 

The function: 

FN4JL: 

DEF* FN4%(Xl%,X2%) 

FN4%=-1% 

E%=1% i*DATE ADDER 

GOTO FN4_4 IF Xl%<0% 

GOTO FN4_3 IF X2%=0% !*CHECK PARAMETER VALUE 

FN4_2: 

X4%=Xl%/1000%-70% 

X4%=X4%-X4%/ 4%*4% 

IF X4%=-3% AND X2%<0% 

THEN X4%=0% 

ELSE X4%=-1% UNLESS X4%=0% AND X2%>0% 

END IF 
X5%=X2% 

X5%=SGN(X2%)*(366%+X4%) IF (SGN(X2%)*X5%)>366%+X4% 

X2%=X2%-X5% 

I*X4%=0 IF A LEAP YEAR 
!*X2%=AM0UNT TO ADD OR SUBTRACT 
!*(ONE YEAR AT A TIME) 

X3%=X1%+X5% 

GOTO FN4_4 IF X3%>29365% OR X3%<0% 

X6%=X3%-X3%/1000%*1000% 

IF ((X6%>366%+X4%) AND SGN(X5%)>0%) & 

OR ((SGN(X5%)<0%) AND (X6%=0% OR X6%>366%+X4%)) THEN 
X3%=X3% + SGN(X5%)*(634%-X4%) 

END IF !*ADD OR SUBTRACT THE DAYS 

!*TEST FOR YEAR OVERFLOW 

X1%=X3% 

GOTO FN4_2 IF X2% !*RESET START DATE 

!*BACK TO ADD OR SUBTRACT SOME 
!* MORE 

FN4_3: 

FN4%=Xl% 

E%=0% I*FN4%=RESULTANT DATE 

!*INTEGER 

!*N0 ERRORS WERE MADE 

FN4_4: 

FNEND 

And after you have a julian date, and you can add or subtract days, you 
might want to know what day of the week it is. To do that you have to 
let your program know that there are seven days in a week. This function 
will do that for you. 
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Parameters: 

Julian date 
Returned: 

Numeric day of the week 
The function: 


FN5_1: 

DEF FN5(X) = 7 * (X/7 - INT(X/7)) 

These functions can be used in programs to serve some kind of a useful 
purpose. This program is used to requeue a batch control file. 
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THIS PROGRAM WILL AUTOMATICALLY REQUE A BATCH FILE 
TO A GIVEN HANDLER. THERE IS ONE PROMPT: 

INPUT FILE? 

TO THIS RESPOND: 

filename;days-of-the-week;time-of-reque;#-of-handler 

THE DAYS OF THE WEEK IS A STRING OF DIGITS, WHERE 0 IS 
SUNDAY. THIS STRING CAN BE IN ANY ORDER. 

EXAMPLE: 

TEST.CTL;13205;04:00;3 

WHERE TEST.CTL IS THE FILE TO REQUE 

13205 INDICATES THAT THE JOB WILL BE QUEUED 

ON MONDAYS,WEDNESDAYS,TUESDAYS,SUNDAYS,AND FRIDAYS 

04:00 IS THE TIME OF DAY TO QUEUE THE JOB 

3 IS THE NUMBER OF THE BATCH HANDLER TO QUE THE JOB TO 

ALL SEMICOLONS ARE REQUIRED. DEFAULT DAYS ARE 12345. DEFAULT 
TIME IS 04:00. DEFAULT HANDLER IS THE FIRST FREE ONE. 


* IN ORDER TO EXECUTE THIS ROUTINE, THE 

* FOLLOWING MUST BE AT THE START OF THE 

* BATCH CONTROL FILE: 

* 

* $JOB/NAME=jobname/NOLIMIT/CCL 

* $RUN (1,4)REQUE 

* ctl-filename;days;time;handler 

* $EOD 

*F1$=NAME OF CONTROL FILE INPUT—IF NO .EXT, DEFAULTS TO .CTL 

*V$=DESIRED DAYS OF THE WEEK 

*T$=DESIRED TIME OF DAY 

*H$=BATCH PROCESSOR NUMBER 

*D$=DATE TO BE USED FOR QUE COMMAND 

*D2$=CURRENT DATE + 11%, INCREMENTED BY 1 UNTIL IT = ONE 
*OF THE DAYS IN V$ 

*IF NO DAYS OF THE WEEK, DEFAULTS TOM,T,W,T,F 

*IF NO TIME, DEFAULTS TO 18:000 

*IF NO BATCH PROCESSOR, DEFAULTS TO * 
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Wl% = 2% 


FN2 1: 


!* THIS IS THE NUMBER OF THE 1ST DAY OF 
!* 1980, WHERE MONDAY IS ONE(l). 

PRINT "INPUT FILE"; 

INPUT LINE Fl$ 

F1$=EDIT$(Fl$,2%+4%) 

F1$=FN1$(Fl$,";") 

V$=FN1$(X2$,";") 

IF VAL(V$) > 7 THEN 

PRINT "ILLEGAL DATE FORMAT" 

GOTO 32767 

END IF 

T$=FN1$(X2$,";") 

IF LEN(T$) <> 0% AND INSTR(1%,T$,":") = 0% THEN 
PRINT "ILLEGAL TIME FORMAT" 

GOTO 32767 

END IF 
H$=X2$ 

V$="12345" IF LEN(V$)=0% 

T$="18:00" IF LEN(T$)=0% 

H$="" IF LEN(H$)=0% 

11 % = 1 % 

!* THIS IS THE NUMBER OF DAYS TO SKIP 
!* BEFORE REQUEUEING THE NEXT BATCH JOB. 

100 D%=FN4%(FN3%,11%) 

X%=FN3%/1000% + 69% 

Dl%=0% 

D1%=FN2%("31-DEC-"+NUM1$(1%)) & 

- (FN2%("31-DEC-"+NUMl$(1%))/1000%)*1000% + Dl% FOR I%=80% TO X% 

D1%=D1% + Wl% + (D% - ((D%/1000%)*1000%)) - 1% 

D2% = Dl% - ((Dl%/7%)*7%) 

D2$=NUM1$(D2%) 

IF INSTR(1%,V$,D2$)=0% THEN 11% = 11% + 1% 

GOTO 100 

END IF !* THIS CALCULATION DETERMINES WHAT DAY OF 

i* THE WEEK THE NEW DATE IS( l=MONDAY ). 

!* IF THE DAY IS NOT ONE SELECTED THEN 
!* IT SKIPS TO THE NEXT DAY AND 
!* CHECKS IT FOR VALIDITY. 

D$=DATE$(D%) 

L%=32767% !* THIS IS THE LINE # TO RETURN TO AFTER THE 

I* QUE ROUTINE HAS BEEN CALLED. 

X$=SYS(CHR$(8%)+"(1,4)REQUE"+CHR$(13%)+CVT%$(L%)+"Q BA"+H$+":/AFTER:"+ & 
D$+":"+T$+"="+Fl$+CHR$(13%)) 

CHAIN "$QUE" LINE 31000% 

FN1_1: 

DEF* FN1$(X0$,X1$) 

X%,Xl%=INSTR(1%,X0$,Xl$) 

X%=LEN(X0$)+1% UNLESS X% 

FN1$=LEFT(X0$,X%-1%) 

X2$=RIGHT(X0$,X%+LEN(Xl$)) 

!*PARSE X0$ INTO FN1$ AND X2$ 


DEF* FN2%(X$) 

X$=DATE$(0%) IF X$="TODAY" 

X$=LEFT(X$,2%)+"-"+MID(X$,3%,2%)+"-"+RIGHT(X$,5%) & 

IF LEN(X$)=6% UNLESS INSTR(1%,X$,"-") 
X4%=INSTR(1%,X$,"-") 

X5%=INSTR(X4%+1%,X$,"-") 

E%=1% 

FN2%=-1% 

IF X$="00-XXX-00" THEN 
X8%=-1% 

GOTO FN2_2 

END IF 

GOTO FN2_3 IF X4%*X5%=0% 

X6%=VAL(RIGHT(X$,X5%+1%))-70% 

GOTO FN2_3 IF X6%<0% OR X6%>29% 

X6%=X6%*1000% 

X6%=X6%+243% IF INSTR(1%,"S0ND",EDIT$(MID(X$,X4%+1%,1%),32%)) 

IF X5%-X4%<4% THEN 

X7%=VAL(LEFT(X$,X4%-1%)) 

GOTO FN2_3 IF X7%<1% OR X7%>12% 

X$=MID(X$,X4%+1%,X5%-X4%) & 

+RIGHT(DATE$((X7%-1%)*31%+1%+X6%),4%) 

X6%=X6%+(X7%-1%)*29% 

END IF 

X$=EDIT$(X$,34%) 

X$="0"+X$ IF INSTR(1%,X$,"-")=2% 

GOTO FN2_2 IF X$=EDIT$(DATE$(X8%),32%) FOR X8%=X6%+1% TO X6%+366 
GOTO FN2_3 

FN2_2: 

E%=0% 

FN2%=X8% 

FN2_3: 

FNEND 

DEF* FN3%=SWAP%(CVT$%(RIGHT(SYS(CHR$(6%)+CHR$(-3%)),27%))) 

]*NON-PRIV WAY OF GETTING TODAY'S JULIAN DATE 

FN4_1: 

DEF* FN4%(X1%,X2%) 

FN4%=-1% 

E%=1% 

GOTO FN2_4 IF X1%<0% 

GOTO FN4_3 IF X2%=0% 

FN4_2: 

X4%=Xl%/1000%-70% 

X4%=X4%-X4%/4%*4% 

IF X4%=-3% AND X2%<0% 

THEN X4%=0% 

ELSE X4%=-1% UNLESS X4%=0% AND X2%>0% 

END IF 
X5%=X2% 

X5%=SGN(X2%)*(366%+X4%) IF (SGN(X2%)*X5%)>366%+X4% 

X2%=X2%-X5% 


!*DATE ADDER 
!*CHECK PARAMETER VALUE 


FNEND 
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!*X4%=0 IF A LEAP YEAR 
!*X2%=AMOUNT TO ADD OR SUBTRACT 
!*(ONE YEAR AT A TIME) 



X3%=xl%+X5% 

GOTO FN2_4 IF X3%>29365% OR X3%<0% 

X6%=X3%-X3%/1000%*1000% 

IF ((X6%>366%+X4%) AND SGN(X5%)>0%) & 

OR ((SGN(X5%)<0%) AND (X6%=0% OR X6%>366%+X4%)) THEN 
X3%=X3% + SGN(X5%)*(634%-X4%) 

END IF i*ADD OR SUBTRACT THE DAYS 

!*TEST FOR YEAR OVERFLOW 

X1%=X3% 

GOTO FN4_2 IF X2% PRESET START DATE 

!*BACK TO ADD OR SUBTRACT SOME 
!* MORE 

FN4_3: 

FN4%=X1% 

E%=0% !*FN4%=RESULTANT DATE 

!*INTEGER 

!*NO ERRORS WERE MADE 

FN2_4: 

FNEND 

32767 END 

This program returns the day of the week. This seed version returns 
today's date, but it can be modified to give other days. 


10 GOSUB 600 

GOTO 32767 


600 


! THIS SUBROUTINE WILL RETURN 
! THODAY'S DAY OF THE WEEK 

MTH_$ = "JANFEBMARAPRMAYJUN JULAUGSEPOCTNOVDEC" 
YR_$ = EDIT$(DATE$(FN3%), 32%) 

MTH_% = (INSTR(1%, MTH_$, YR__$) + 2%)/3% 

YR_% = VAL(LEFT (NUM1$(FN3%), 2%)) 

DY_% = VAL(RIGHT(NUM1$(FN3%), 3%)) 


DATE_$(0%) 
DATE_$(1%) 
DATE_$(2%) 
DATE_$(3%) 
DATE_$(4%) 
DATE_$(5%) 
DATE_$(6%) 
DATE_$(7%) 


" FRIDAY" 

" SATURDAY" 
" SUNDAY" 

" MONDAY" 

" TUESDAY" 

" WEDSNDAY" 
" THURSDAY" 
" FRIDAY" 


IF MTH_% > 2% THEN 

MTH_% = MTH_% - 2% 

ELSE 

MTH_% = MTH_% + 12% 
YR_% = YR_% - 1% 
MTH_% = MTH_% - 2% 

END IF 


ANS_% = (INT (FN5 (INT (2.6*MTH_% - .2) + DY__% + YR_% & 
+ (YR_%/4%) - 32.95)) + 1%) 


PRINT DATE_$ (ANS_%) 


ANS_% = 0% IF ANS_% = 7% CL-7 


FN3_1: 

DEF* FN3%=SWAP%(CVT$%(RIGHT(SYS(CHR$(6%) +CHR$(-3%)),27%))) 

J*NON-PRIV WAY OF GETTING TODAY'S JULIAN DATE 

FN5_1: 

DEF FN5(X) = 7 * (X/7 - INT(X/7)) 

32767 END 


This is a modification of the seed program. 

600 1 DAYOWK MODIFIED TO DETERMINE LAST FRIDAY AND SATURDAY 

MTH_$ = "JANFEBMARAPRMAYJUNJULAUGSEPOCTNOVDEC" 

YR_$ = EDIT$(DATE$(FN3%), 32%) 

MTH_% = (INSTR(1%, MTH_$, YR_$) + 2%)/3% 

YR_% = VAL(LEFT (NUM1$(FN3%), 2%)) 

DY_% = VAL(RIGHT(NUM1$(FN3%), 3%)) 

IF MTH_% > 2% THEN 

MTH_% = MTH_% - 2% 

ELSE 

MTH_% = MTH_% + 12% 

YR_% = YR_% - 1% 

MTH_% = MTH_% - 2% 

END IF 

ANS__% = (INT (FN5 (INT (2.6*MTH_% - .2) + DY_% + YR_% & 

+ (YR_%/4%) - 32.95)) + 1%) 

ANS_% = 0% IF ANS_% = 7% 

FRI_% = FND2% (FN3%, -ANS_%) 

SAT_% = FND2%(FN3%, -ANS_% - 6%) 

FRI_$ = DATE$(FRI_%) 

SAT_$ = DATE$(SAT_%) 

RETURN 


We all have a little MAGIC 

Please take the time to share your's with the other members of the 
Conmercial Languages SIG. 


CL-8 


RETURN 
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Contributions 


Contributions to the newsletter can be sent to either of 
the following addresses: 


Editor, DMS SIG Newsletter 
c/o DECUS U.S. Chapter 
219 Boston Post Road, BP02 
Marlboro, MA 01752 


Russ Poisson 

DMS SIG Newsletter Editor 
SEED Software Corporation 
2121 Eisenhower Avenue 
Alexandria, VA 22314 


Letters and articles for publication are requested from members 
of the SIG. They may include helpful hints, inquiries to other 
users, reports on SIG business, summaries of SPR's submitted to 
DEC, etc. Machine readable input is highly desirable. 

Submitters should keep in mind the DECUS policy on commercialism. 


Calling All Hands 


DMS SIG is in need of a Membership Coordinator. If you are 
interested in this leadership position within the DMS SIG, 
please call the DMS SIG CHAIRMAN Joseph F. Sciuto at 
(202) 274-9420. 

Volunteers Needed - Volunteers are needed to participate in 
user panels, chair sessions, and help in the DMS SIG campground 
at the Spring ’86 DECUS Symposia. volunteers should call the DMS 
SIG Symposia Coordinator Keith Hare at (614) 587-0157. 
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219 Boston Post Road, BP02 
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Letters and articles for publication are requested from members 
of the SIG. They may include helpful hints, inquiries to other 
users, reports on SIG business, summaries of SPRs submitted to 
Digital or other information for members of the DATATRIEVE SIG. 
Machine readable input is highly desirable and machine-to-machine 
transfer of material is preferred, but most anything legible will 
be considered. However, this newsletter is not a forum for job 
and/or head hunting, nor is commercialism appropriate. 
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About the Cover 


It is April tomfoolery time and the Wombat has always been one to 
enjoy a practical joke or two. In seriousness, however, we are 
quickly approaching the Sping DECUS Symposia, where some very 
good information and fun are shared by all. 


Chairman's Corner 

Joe H. Gallagher, SIG Chair Elect, Research Medical Center, 
Kansas City, MO 


It's almost time for another symposium. Time has really 
flown since last December in Anaheim. This has been a time of a 
lot of change for me (a new job in a new town and a new job in 
the DTR/4GL SIG). I am looking forward to the activities in 
Dallas with great expectation. I was born and raised in Fort 
Worth so it will be a change to return to a familiar town; 
Digital will have "officially" announced their new fourth genera¬ 
tion language products, Rally and Teamdata; and I will again be a 
SIG chair (I was SIG chair of the PDP-9 and PDP-15 group called 
SIG-18 back in 1974 to 1979, and I should have been smart enough 
to keep them from talking me into this again). 

The Dallas Symposium will be the 25th Anniversary of DECUS 
and there will be special activities: a real Texas Bar-B-Q, a 
keynote by Admiral Grace Hopper, birthday cake, memorabilia show, 
and trivia contest in addition to the usual quality sessions. 
The sessions sponsored by the DTR/4GL SIG are listed elsewhere in 
this issue. "Karnak the Befuddled" is also scheduled to make 
another appearance at Wombat Magic and the SIG is trying to ar¬ 
range a special door prize for everyone for Wombat Magic. 

The weather should be great in Dallas during the sympo¬ 
sium. So I'll look forward to seeing you there and greeting you 
with a great big Texas "Howdy." 


From the Editor's Pen 

Donald E. Stern, Jr., Warner Lambert Company, Milford, CT 


By the time this issue of the newsletter reaches the readership, 
the Dallas Symposium should be rapidly approaching. The DTR/4GL 
SIG is once again planning a full range of sessions from Novice 
to Advanced/Technical in orientation. In addition, pre-symposium 
seminars have been organized and will be well worth attending. 
As always, a WOMBAT MAGIC session has been scheduled and should 
definitely be placed on your "must attend" list of activities. 

An issue of the Wombat Examiner and 4GL Dispatch would not be 
complete without the editor's plea for reader participation. 
Please help keep the newsletter vital by contributing an article, 
a problem, or a solution to a problem. 

See y'all in Dallas! 
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DTR/4GL SIG SESSIONS at U. S. DECUS SPRING 1986 SYMPOSIA 

Chris Wool, DTR/4GL Symposia Committee Representative 


This is a preliminary listing of talks scheduled for the 
U.S. DECUS Spring 1986 Symposium. 

Attendees are warned to watch UPDATE.DAILY at the symposia 
for schedule updates. 


Campground - 

The DTR/4GL and Data Management SIGs will share a camp¬ 
ground in Dallas. There will be a MicroVAX II and PRO/350 in the 
campground and they will have DATATRIEVE, 4GL, and VIA products 
available for demos and aiding in solving any problems you may 
have. 

SUITE - 


The DTR/4GL and Data Management SIGs will also share a 
suite at Loews Anatole Hotel (this is the official DECUS hotel, 
although there are no hotels officially associated with the con¬ 
vention). Look for the suite number at the convention registra¬ 
tion booth. 

Bookstore - 

The DECUS bookstore will carry souvenirs including Wombat 
magnets and pins. The pins will have a special anniversary sale 
price this symposia, so be sure to pick-up a few for your friends 
and fellow workers back home. 


Pre-Symposia Seminars 


DTR/4GL SIG will sponsor two pre-symposia seminars on 
Sunday, April 27. 

9:00 - 5:00 Basic DATATRIEVE 

9:00 - 5:00 Advanced VAX-11 DATATRIEVE 


SESSIONS 


Monday 


9:00- 

10:00 

DMS and DTR/4GL SIGs Opening Session 

12:30 

-1:30 

What are 4th Generation Languages Anyway? 

1:30- 

2:30 

VAX TEAMDATA and VAX RALLY: New 



Generation Solutions 

2:30- 

3:00 

What is ADE? 


(Continued...) 
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3:00- 

4:00 

3:00- 

4:00 

3:00- 

4:00 

5:00- 

6:00 

6:00- 

7:00 

7:00- 

7:30 

7:30- 

8:00 

8:00- 

8:30 

9:00- 

10:00 

10:00 

-11:00 

11:00 

-12:00 

12:00 

- 1:00 

1:00- 

2:00 

2:00- 

3:00 

3:00- 

4:00 

4:00- 

5:00 

5:00- 

6:00 

9:00- 

10:00 

10:00 

-11:00 

11:00 

-12:00 

12:00 

- 1:00 

1:00- 

2:00 

4:00- 

6:00 

9:00- 

10:00 

10:00 

-11:00 

11:00 

-12:00 

12:00 

- 1:00 

1:00- 

2:00 

2:00- 

3:00 

3:00- 

3:30 

3:30- 

4:30 

1 

o 

CO 

5:30 

5:30- 

6:30 

8 : 00 - 

10:00 

10:00 

-11:00 

11:00 

-12:00 

12:00 

- 1:00 


Monday (continued) 

Accessing Remote Data with VAX DATATRIEVE 
Introduction to the A-to-Z Application 
Generator 

DECREPORTER - A Commercial Report Generator 
DATATRIEVE-11 Internals and Performance 
Optimization 

DATATRIEVE and RMS Tuning 

Using DATATRIEVE as a COBOL Code Generator 
A Case Study of a Job Description Reporting 
System 

The SAR Data Catalog System 

Tuesday 

So What is DATATRIEVE Anyway? 

So Why use DATATRIEVE Anyway? 

Commonly asked DATATRIEVE Questions 
VAX DATATRIEVE Internals 

Technical Overview of the A-to-Z Application 
Generator 

Designing an Application using the A-to-Z 
Application Generator. 

Directions in 4th Generation Languages 

VAX DATATRIEVE to DATATRIEVE-11 Conversion 

Panel 

DATATRIEVE Novice Questions and Answers 

Wednesday 

Design and Implementation of a 4th 

Generation Language 

VAX RALLY Technical Overview 

VAX TEAMDATA - End-User Information 
Management 

TEAMDATA and RALLY Field Test Panel 
End User Computing with INTELLECT 
DATATRIEVE Software Clinic 

Thursday 

Accessing Relational Databases through VAX 
DATATRIEVE 

VAX DATATRIEVE Record Definition Workshop 
DATATRIEVE Application Design Tutorial 
VAX DATATRIEVE Application Design Trade-offs 
Integrating DATATRIEVE and ALL-IN-ONE 
DATATRIEVE in the Epidemiological Research 
Environment 

DATATRIEVE Sequential File Record Deletes 
Calling DATATRIEVE-11 from High Level 
Languages 

Using VAX DATATRIEVE with the Forms 
Management System 
Customizing VAX DATATRIEVE 

Wombat Magic 

Friday 

Using VAX DATATRIEVE Graphics 
Integrating DATATRIEVE, DECALC, DECGRAPH 
DTR/4GL SIG Closing Session 
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VAX DATATRIEVE INTERNALS 

Sue Harris, VAX DATATRIEVE Group, Digital Equipment Corp. 


This article is a summary of the DATATRIEVE Internals talk which 
was presented at Fall DECUS 1985. 


1 ARCHITECTURAL OVERVIEW 

VAX DATATRIEVE is not just a sharable image, but a group of seve¬ 
ral interconnected sections we call the "BOXES". Not all of 
these are strictly a part of the product VAX DATATRIEVE, but the 
end user may see them as a whole: 

o The underlying File Structures are of course, RMS, 
DBMS, and Rdb. 

o DATATRIEVE also has tightly connected interfaces to 
FORMS interfaces, CDD, and the DDMF (for remote proces¬ 
sing) . 

o The main "BOX" containing most of the DATATRIEVE code 
consists of the sharable image (DTRSHR.EXE) and the 
terminal server (TERMSERVE.OLB). 

o 'The "top level" of DATATRIEVE consists of ADT, EDT, 
GUIDE, HELP, the interactive task DTR32xx.exe, and 
callable programs. All of these are 'separable' por¬ 
tions of VAX DATATRIEVE that can interface to the main 
box. 


2 DATATRIEVE STARTUP TASKS 

Two activities occur upon DATATRIEVE startup: image activation 
and DATATRIEVE initialization. 

Image activation is actually performed by VMS on behalf of DATA¬ 
TRIEVE; however, since it does add to the startup time it's use¬ 
ful to review. The sharable images linked with VAX DATATRIEVE 
are DTRSHRxx, CDDSHR, VMSRTL, LBRSHR, SCRSHR, and optionally, 
FDVSHR, if you specified FMS support. 

Note that the list of images is significantly smaller than in 
pre-V3.2 releases; now VAX DATATRIEVE does dynamic image activa¬ 
tion for DBMS, Rdb, TDMS, SORT, and EDT (VAX DATATRIEVE cannot do 
dynamic image activation for the FMS image). 

DATATRIEVE initialization begins with initialization of a user 
DAB (a DATATRIEVE ACCESS BLOCK is used internally for each inter¬ 
active DTR user, as well as for callable programs). Next, DATA¬ 
TRIEVE allocates memory for its internal data structures, and 
loads the Hash table. 


The Hash table is an internal data structure used to hold and 
locate (via a hashing algorithm) all known 'names'. At startup 
time, DATATRIEVE must enter into the Hash table all keywords, 
UDKs, function names, and synonyms from startup files. 

The next step in initialization consists of 'signing in' to the 
CDD. The CDD, itself, will translate the logical name 
CDD$DEFAULT and will ultimately be the one to actually open the 
CDD.DIC file (and any appropriate subdictionary files which exist 
for the default pathname). 

Next, DATATRIEVE initialization will create a temporary work file 
called SYS$SCRATCH:DTRWORK.TMD. This work file will be used 
later in processing to maintain record-ids for records in collec¬ 
tions, SORTs, etc. 

Finally, DATATRIEVE will translate the logical names 
SYS$CURRENCY, SYS$RADIX_POINT, SYS$DIGIT_SEP, DTR$DATE_INPUT, and 
will execute the DTR$STARTUP and DTR$SYNONYM files. 


3 DATATRIEVE STAGES 

Datatrieve commands and statements are processed one at a time. 
A different path is taken depending on whether the user input to 
DTR is a command, a statement, or a statement involving remote 
access. The steps in these paths are called stages: 


| LEXICAL ANALYSIS I 


I PARSING | 


I COMMAND EXECUTION | 


(STATEMENT PRECOMPILATION ( 


(STATEMENT COMPILATION I 


| STATEMENT DECOMPILATION | 


(STATEMENT EXECUTION 
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3.1 Lexical Analysis 

The user lines typed in response to the DATATRIEVE prompt are the 
input to the lexical analysis phase. The object of this phase in 
DATATRIEVE processing is to produce TOKENS. Tokens are the low¬ 
est level syntactic element and they consist of keywords, identi¬ 
fiers, punctuation, numbers and quoted strings. 

Example: 

FOR FIRST 5 YACHTS PRINT BUILDER, "QUOTED STRING" 

Tokens produced: 

FIRST 

5 

YACHTS 

PRINT 

BUILDER 

"QUOTED STRING" 

*** END_OF_LINE *** 

During this phase, DATATRIEVE will also do Hash table lookups. 
That is: names, keywords, and identifiers are checked against the 
values in the Hash table. If the token is in the Hash table, an 
association is made between the token and the Hash table value. 

Remember that the Hash table contains most known 'names': key¬ 
words, UDKs, synonyms, function names from startup time; domain 
names, list names, and DBMS set names from READY commands; syno¬ 
nyms from DECLARE SYNONYM, collection names from FINDs, and table 
names from the use of VIA or IN clauses. 

During this phase, DATATRIEVE will also do its line continuation 
("Looking for xxx..." messages), and !CMD and !VAL substitution 
for input from callable programs. 


3.2 Parsing 

The input to this stage is the list of tokens produced from the 
lexical phase. The main task of this stage is to do syntax veri¬ 
fication and to create a data structure which delineates each 
syntax element of the input statement. This data structure is 
called the 'syntax tree' because it is represented and interpret¬ 
ed internally as a hierarchical structure. 

Example: 

FOR FIRST 5 YACHTS PRINT BUILDER, "QUOTED STRING" 

The 'syntax tree' which is built by parsing this statement: 

FOR 

RSE 

PRINT: PRINT LIST 


The data structure obviously contains more information than is 
presented here, but the main point of this diagram (and subse¬ 
quent ones) is to identify the overall structure. In this case, 
the important fact is that the input statement has been decompos¬ 
ed by DATATRIEVE into its syntactic elements of an RSE, followed 
by a print list. 

Another very important task of this stage is to determine whether 
or not the user typed a command or a statement. If the input was 
a statement, then the 'syntax tree' structure we just examined 
will be created and more stages of processing will be needed for 
the statement. 

If, however, the user typed in a command, the processing for the 
command is totally different. To explore this further we need to 
discuss the next optional stage of processing. 


3.3 Command Execution 

Commands change the environment and create a link to data; state¬ 
ments are context controlled and manipulate data. Statements 
need stability of the environment to allow DATATRIEVE to do com¬ 
pilation of the statements, and especially, to allow optimization 
of the statements. Therefore, commands must be processed immedi¬ 
ately after parsing (this is also why commands cannot be embedded 
in statements). 

As an example, consider the command READY YACHTS. The output from 
executing this command is that a hierarchical data structure 
called the 'field tree' is built to describe all the fields for 
the domain. This hierarchical structure is built by repeated 
calls to the CDD for each field in the domain, and contains ALL 
known information about each such field. 

Also, as part of the READY command, the RMS file will be opened 
if the domain was based on an RMS source; the form library, if 
any, is opened; the domain name is entered into the Hash table; 
names for any list fields in the domain are entered into the Hash 
table. 

Note that these results of the READY command provide context for 
subsequent statements. 


3.4 Statement Precompilation 

If the user had typed in a command, then the stage of command 
execution completes the processing for that input. If however, 
the user typed in a statement, there are additional stages of 
processing. The precompilation stage is the next, and takes as 
its input the 'syntax tree' structure which was created by the 
parsing stage. 

The main job of this stage is to do a 'binding' to the environ¬ 
ment, since the environment is determined to be stable (for at 
least the rest of this statement). There are really 3 types of 
binding which are done: 
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o Name resolution using the Hash table. For example, if 
the name is not found, you might see the error message 
'"YACHT" is not a readied source, collection, or list'. 

o Context searching and resolution. 

o Expansion of the input 'syntax tree' to include infor¬ 
mation about the environment. For example, group items 
in print and modify lists will be expanded into the 
individual field items. Views will be expanded into 
the structure by essentially expanding the RSEs from 
the view into the 'syntax tree' for the statement. 

The result of this binding to the environment is essentially the 
same 'syntax tree' but with expansions, and with contexts and 
names resolved. 

Finally, this is the last phase during which the dictionary is 
accessed, and it is the phase during which plots are loaded into 
memory, if needed. 

3.5 Statement Compilation 

The input to-this stage is the 'precompilation tree' structure. 
The main tasks of this stage are to construct and optimize record 
streams, to optimize and datatype all values, to factor invariant 
expressions from loops, to compile Rdb requests to BLR, and to 
determine if this statement is a request for remote access. 

The output of this stage is another hierarchical data structure 
called the 'execution tree'. 

Example: 

FOR FIRST 5 YACHTS PRINT BUILDER, "QUOTED STRING" 

The output 'execution tree' is: 

FOR 

FIRST 5 OF 

<get first/next record from the yachts file; nonkeyed> 
PRINT 

PRINT-LIST (first column:l last column:14) 
PRINT FIELD: MANUFACTURER 

PRINT CONSTANT: "QUOTED STRING" 

Note the level of detail in this example: DTR has determined that 
it cannot use keyed access to this file and it has analyzed the 
field datatypes and lengths enough to know the exact output for¬ 
mat . 

When you run the DATATRIEVE image in debug mode, DTR prints out 
additional informational messages during the compilation stage. 
For example, if DTR had decided that it could use keyed access to 
the YACHTS domain in the above example, it would print a message 
indicating the type of keyed access (EQ, GT, etc.) and the name 
of the keyed field. 


3.6 Statement Decompilation 

If the Statement Compilation stage had determined that the state¬ 
ment needed remote access, processing would be diverted at this 
point to do statement decompilation. Remember that DATATRIEVE's 
remote facility must interface to DTR-11 and DTR-20, which cannot 
interpret VAX DATATRIEVE's internal structures. So, the task of 
this stage is to 'decompile' the internal data structure for the 
statement back to an external statement suitable for sending to 
the remote facility (note that much of the error checking for the 
statement has already been done on the host system). 

Since remote access is a separate and large topic in itself, it 
will not be discussed further here, except to note that by run¬ 
ning VAX DATATRIEVE in debug mode, you can see the commands which 
are sent to the remote server. The commands are also logged on 
the remote system in NETSERVER.LOG. 


3.7 Statement Execution 

Note that up until this point, only internal data structures have 
been built; no user data has been accessed yet. 

The input to this stage is the 'execution tree' built by the 
compiler. DATATRIEVE 'walks' this data structure, finally doing 
the real work: 

o Manipulates the data 

o Does output of PRINTS and REPORTS 

o All RMS locking is done at this level; Rdb and DBMS 
locking is done on behalf of the DTR user during this 
stage 

o DTR interacts with the "User" (prompts, etc.) 

It's interesting to note that while this stage is finally doing 
the real work, it is also a "dumb" stage in the sense that it can 
only do what has been determined by the compiler: it can only 
follow the 'execution tree' and do what it implies. 

Looking back at the example 'execution tree' from the compilation 
stage, realize that DATATRIEVE will interpret the FOR structure 
as a loop. It will look at the data structures which are hierar¬ 
chically subordinate to the FOR, execute each, and loop back to 
the FOR again, until there are no more records in the YACHTS 
f ile. 


4 PROCEDURE CONSIDERATIONS 

Procedures are stored as text strings, they are NOT stored in a 
compiled form. This is necessary because of the dynamic changing 
of the environment that DATATRIEVE allows: each statement is 
compiled based on the current set of names and contexts, not 
based on a 'static' set of names and contexts that existed at the 
time of a compile. 
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The entire procedure is expanded into tokens at one time in order 
to minimize dictionary access, but other stages are done a com¬ 
mand or statement at a time. This is what allows commands to 
I create the context for subsequent statements. 

| Note: compound statements are treated as a SINGLE compilable 
| unit. This has important implications which you may want to 
consider. 

I For example, use of loops (REPEAT, WHILE, FOR) are more efficient 
than executing a procedure which must repeatedly be compiled for 
every invocation. 

Also realize that CHOICE statements are compiled as one unit -- 
including any sub-procedures that the CHOICE statement may in¬ 
voke. One unexpected side effect of this is that CHOICE state¬ 
ments may sometimes 'seem' slower than multiple IF-THEN state¬ 
ments. Ultimately, the same amount of work must be done for both, 
but the CHOICE can seem longer because ALL choice options must be 
compiled before any execution (any user interaction) is seen, 
whereas if multiple IF-THENs are used, some user interaction may 
I be seen earlier if the chosen alternative occurs early in the 
list. 

To avoid compilation of unused choice alternatives, you can po¬ 
tentially use logical names: 

Example: 

DECIDE_IT = *."Value to choose" 

IF DECIDE_IT = 1 THEN FN$CREATE_LOG ("proc", "prod") 

IF DECIDE_IT = 2 THEN FN$CREATE_LOG ("proc", "proc2") 

: PROC 

In this example, only the chosen procedure is compiled by DATA- 
TRIEVE. 


4.1 Collection Considerations 


While FIND is technically rated as a statement, it also puts the 
collection name in the Hash table, which is essentially a kind of 
'context' operation. Subsequent statements need that name to 
resolve context. FINDs, therefore, are not recommended in com¬ 
pound statements because collection references must be after the 
entire compound statement completes. This is also why SELECTS 
are not supported in BEGIN/END blocks. 


f Example (not supported!): 

READY YACHTS, OWNERS 
FIND ALL YACHTS 
BEGIN 

FIND OWNERS 

SELECT 

PRINT 

END 

= Note: A YACHTS record is printed! Should use FOR statement in- 
stead: 


READY YACHTS, OWNERS 
FIND ALL YACHTS 
BEGIN 

FOR FIRST 1 owners 
PRINT 

END 
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This session was originally planned to be a recounting of 
users' experiences in converting to VAX-DTR from DTR-11. Due to 
various difficulties which arose between scheduling the session 
and the symposium (such as non-functioning equipment, and jobs 
being eliminated), the final panel had to speak partially from 
experience and partially on generic terms. Nevertheless, many 
important points were covered, and the information was judged to 
be quite useful by those attending the session. This is not 
intended to be an exact transcription of the session: rather, it 
simply presents the information in a readable form. I will not 
attempt to distinguish which person made what contributions. I 
would also like to acknowledge the presence of Suellen Harris and 
Bill Opalka from DEC, who sat in the audience and kept us from 
going astray. 


Major Points. 

DTR-11 is an almost perfect subset of VAX-DTR. 

DTR-11 is a nearly perfect subset of VAX-DTR. It was, of 
course, developed first and VAX-DTR was developed later using the 
same syntax so users could migrate. The primary point of diffi¬ 
culty has to do with a difference in how the hardware addresses 

memory. The PDP-11 cannot address a word which starts on an odd 

byte boundary, while the VAX can: therefore, such data types as 
REAL, DOUBLE, INTEGER, DATE, and other word, double word, and 
quad word variables, must be aligned to word boundaries on the 
PDP-11. DTR-11 will automatically do this by inserting invisible 
bytes where needed. Consider the following record definition: 

01 RECORD. 

10 FIELD1 PIC X. 

10 FIELD2 PIC 99 USAGE IS INTEGER. ; 

FIELDl is one byte long, and FIELD2 is two bytes long. In 
VAX-DTR, this record would be 3 bytes long: on the PDP-11, it 
will be 4 bytes long, as an extra byte has to be inserted between 

the two fields to make FIELD2 start on an even byte boundary. 

DTR-11 will do this wherever necessary (and only where neces¬ 
sary), and does not issue warnings or error messages. This will 
become apparent if the data files are moved from one system to 



another, and the same record definition is used on the VAX with¬ 
out taking precautions. It is possible to make VAX-DTR allocate 
on word boundaries by using the clause 

"ALLOCATION IS LEFT-RIGHT" 

within the record definition; therefore, you should change the 
record definition to: 

DEFINE RECORD TEST_REC USING ALLOCATION IS LEFT-RIGHT 
01 RECORD. 

10 FIELD1 PIC X. 

10 FIELD2 PIC 99 USAGE IS INTEGER. ; 

If you do this, VAX-DTR will allocate space in the same way as 
DTR-11, and there should be no problems. If you don't, you may 
get an error message similar to "RECORD LENGTH DOES NOT MATCH" 
when you try to READY the new domain on the VAX, which is an 
indication that you may have an alignment problem. See also the 
section on moving data below. 

If you do get these messages, and don't do anything about it 
before storing new data, you will corrupt the data file. It 
would be a good precaution to be certain that the first time you 
READY the domain after moving the data that you do so READ ONLY, 
and look at the data. If there are any alignment problems, you 
will immediately see that data isn't coming out correctly, and 
can take corrective measures. 


Planning the move: more dictionary options. 

The Common Data Dictionary has more functionality than the dic¬ 
tionaries on the PDP-11, and some thought should be given to 
using this. On the PDP-11, there is often a separate dictionary 
for each application, and the data files often aren't shared. On 
the VAX, all definitions go into the CDD, which makes sharing 
easier. The CDD has a hierarchical structure, and if you have 
many separate projects you will want to plan which sub¬ 
directories should hold what definitions, and which definitions 
should go into a site common directory (for everyone to use), 
which should go into project wide directories, and which may be 
left in individual directories. The protection options are also 
greater on the VAX than on the PDP-11: if you are not using 
protection now, then you can move with no protection without 
making any changes. If, however, you have been using UIC type 
protection on the PDP-11, then you may want to change, as it is 
unlikely that you will keep the same UIC scheme on your VAX disks 
that you had on your PDP-11 disks (VMS does have UICs, but most 
people go to named directories and hierarchical sub-directories, 
as these tend to be easier to use and more closely follow the way 
most data is organized). Therefore, you may want to change UIC 
and/or password protection, and use some of the new protection 
options available in VMS. 

You do not have to learn much about the CDD before moving if you 
do everything in DTR. You can put everything into one dictionary 
like DTR-11, but you will get better performance if you make a 


good division from the beginning. You can move definitions from 
one sub-section to another later, but it's best to make some 
plans first. A quick read-through of the manual to understand 
the concepts, or attending some DECUS sessions are good ideas. 
For the new user, no new training is needed to begin with, as 
they will see a dictionary just like what they are used to (with 
the addition of version numbers), and can see one big dictionary 
or their own dictionary, whichever matches the PDP-11 installa¬ 
tion; but the person planning the move and organizing the appli¬ 
cation should know something about the CDD. The CDD structure 
can copy the existing PDP-11 setup, but usually matches the com¬ 
pany or application organization. Arranging the dictionary well 
has both performance and maintenance advantages. Note also that 
VAX-DTR can have startup files for individual users just as DTR- 
11 has, to put individuals into the proper dictionary and perform 
READYs or start procedures, as needed: also, the dictionary that 
the user sees for PLOTS can be different from that for all other 
dictionary elements, so the users can get all of their domains, 
records, procedures, and tables from an individual dictionary, 
and at the same time get the PLOTS from the system wide diction¬ 
ary. You might also give them a procedure to set their dictionary 
into the system wide DEMO library if you want them to play with 
YACHTS, EMPLOYEES, or other sample files supplied with DTR. There 
is also a command procedure NEWUSER.COM that comes with DTR that 
can be used to easily set up a dictionary for a new user. In 
addition, there is also a logical name that designates the CDD 
dictionary in which the user will start. 


Moving the data. 

One must move both the data files, and the dictionary objects 
(record definitions, domain definitions, tables, etc.). You can 
EXTRACT individual definitions, but DTR-11 is supplied with a 
utility called QXTR, which will extract all of the definitions in 
a dictionary at one time into a single command file in a manner 
similar to EXTRACT ALL in VAX-DTR. This utility inserts the 
"ALLOCATION IS LEFT-RIGHT" clause into the record definitions, 
which should simplify the move considerably. [This is probably 
true only for DTR-11 V3.0 and V3.1, and not for earlier versions 
of DTR. QXTR is not supplied with PRO-DTR. DTR-11 itself does 
not insert the ALLOCATION clause when extracting.] If you are 
using individual dictionaries for different users, you must ex¬ 
tract each dictionary individually. QXTR also gives you the op¬ 
tion of extracting the protection qualifiers, or not, as you 
choose. This single file can then be moved to the VAX and invok¬ 
ed to re-create all of your records, tables, domains, etc. One 
factor not covered in the original talk is that explicit referen¬ 
ces to disks and/or directories in domain definitions will proba¬ 
bly have to be changed, as your device names will change, and you 
will probably be using symbolic device names and/or named direc¬ 
tories, as mentioned before. To actually get the information 
across, there are several options. 

Moving data on disks. 

If you are using RSX (which in this paper includes 11M, 
HM-Plus, IAS, and possibly 11D), and you have the same kind of 
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disk drive on both systems, or are going to move the disk drive 
to the new system, then you can read your old disks on VMS. You 
will want to copy the information to a new disk, to take advant¬ 
age of some VMS features like named directories, but the files 
can be read while on the old disk, or copied. This applies both 
to the data files, and the file created by QXTR (or the DATA- 
TRIEVE EXTRACT command). If you are running RSTS/E, then you are 
out of luck: no other operating system will read your disks. If 
you don't have a disk type in common on both systems and are not 
moving the devices, you might want to consider plugging in your 
old disk on the VAX just long enough to copy the data, if possi¬ 
ble. If not, then the local DEC office may be able to copy the 
disks, or your local DECUS LUG may help you find a user who may 
let you do it, or you may be able to locate a commercial service 
company that will do it. 

Moving data by Network. 

If both systems run DECNet (no matter what the operating 
system), then any file that DATATRIEVE can read can be read over 
the network. You can COPY (or NFT or FTS) the file with the 
definitions to the VAX, define your domains, copy the data file, 
and be ready to go. Alternatively, you can define two domains 
with the same record definition, with one having a normal file 
specification on the VAX, the second having a file specification 
which includes the node name for the PDP-11 (something you can do 
with VAX-DTR but not DTR-11); or what may be better, if you have 
remote DATATRIEVE installed on the PDP-11 you can use the "READY 
domain AT node" feature of VAX-DTR, and simply read from the old 
domain on the PDP-11 to the new domain on the VAX. This will be 
a little slow, as DTR is not optimized for this type of operation 
the way DECNet utilities are, and the data will be going over the 
network, but hopefully it will only be done once. The advantage 
of doing this is that it can avoid the problems of record align¬ 
ment mentioned before. By using the DTR-11 remote server on the 
PDP-11, the data will be read exactly as it has always been read: 
on the VAX side, you can define a record without the ALIGNMENT 
clause, and pack the data in without worrying about hidden bytes. 
You may also want to consider other methods of converting data 
mentioned below. Remote DATATRIEVE is available starting with 
V3.0, not in earlier versions. If you are not using DECNet, you 
may not have special communications devices normally used for 
networking. DECNet will work over normal asynchronous lines used 
for terminals, however. You may have to give up 8 or 16 lines for 
a while, as DECNet grabs the entire device on PDP-lls, and the 
maximum speed may be 9600 baud so transfers may be a little slow, 
but hopefully you will only do the conversion once. If you don't 
have DECNet, maybe you can persuade the local office to let you 
use it just for a few days while you move your data. 

Moving data on Magnetic Tape. 

If both systems have magnetic tape (or you are moving the 
tape drive), you may be able to store the definitions and infor¬ 
mation on tape. Once again, the RSX family provides the best 
compatibility, with most systems writing ANSI tapes which can be 
read by VMS. (On earlier RSX systems, this was a SYSGEN option, 
so check carefully before you write out the tapes and disconnect 


your PDP-11.) If not, you can write DOS-11 format tapes on all 
RSX family systems which can be read on the VAX with FLX (in 
compatibility mode) or the new EXCHANGE utility. Though you 
might possibly get indexed files over if transferred in image 
mode it will be much more safe if you first convert the data to a 
sequential file and re-construct it on the VAX, as will be men¬ 
tioned again later. If you have RSTS/E, then you are again stuck 
with a system which works differently than everyone else. You 
might be able to generate DOS-11 format tapes, or you may want to 
upgrade to V9.0: this is the latest version of RSTS/E, and it 
includes a utility which writes tapes that are compatible with 
the VMS BACKUP utility. For RSTS/E users this will probably be 
the easiest way to move files, though V9.0 is a new release and 
those of us on the panel have not yet had any feedback from 
users. Moving data from RSTS/E to other systems can be so much of 
a problem that some people plan to upgrade to RSTS/E primarily 
for the purpose of being able to use the new utility to write VMS 
readable tapes with the new utility. 

There is an RMS utility set, BCK and RST, which is intend¬ 
ed for backing up files to and restoring files from magnetic 
tape. These utilities automatically convert indexed files to a 
form which will store properly on magnetic tape, and place error 
checking and other useful information on the tape for all types 
of files. Because they are supplied as part of RMS, they should 
be available on all PDP-11 systems (that can run DATATRIEVE). The 
problem is that VMS may not have a utility corresponding to RST 
to get the data off: so unless you have compatibility mode on 
your VMS system (and it is now an optional layered product), this 
may not be a viable option. 

Other file transfer methods. 

If none of the above are available, you may want to look 
into some of the communications packages which will operate over 
normal serial (terminal) lines. KERMIT is a public domain pro¬ 
gram available from the DECUS library (and elsewhere) which runs 
on virtually any computer and operating system, will work on 
serial lines, does error checking, and can transfer (in most 
cases) both text and binary files. It may be slow, but it will 
work. There are also other communications packages that perform 
similarly: you may even be able to use SET HOST/DTE/LOG on the 
VAX to go in to the PDP-11 and type the file out (this works best 
if the data is all text) or a similar "dumb" text transfer. 


Re-Organizing your data. 

VMS has some options not available on the PDP-11 for in¬ 
dexed files, notably Prolog-3, which allows some space saving. 
Since indexed files should be re-organized occasionally for 
best performance, and since the same data will occupy less space 
in a sequential file and take less time to transfer over net¬ 
works, and transfer more easily on magnetic tape, the time of 
transfer would also be a good opportunity to re-organize and 
optimize the data file by converting it to sequential, and re¬ 
populating an indexed file on the VAX. Even if you can move your 
disk packs and can read your old files directly, re-organizing at 
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this point is a good idea, though in this case you don't have to 
convert to an intermediate sequential file. 

First, you need a description of the current indexed file: 
you can simply make a note of the record length (which you get 
from DTR when you define the record), and figure out where the 
keyed fields are in the record, but there are two RMS utilities, 
the older DSP and the newer DES which are designed to record file 
characteristics and define new files: it's a good idea to have 
such a description file for documentation purposes, even if you 
aren't anticipating a conversion. DES creates a file definition 
which is quite similar to that used by the VMS FDL utility: in 
actual tests, I was very surprised to find that FDL will actually 
read the descriptor file produced by DES! It may give you a few 
warning messages, especially if the SOURCE and TARGET fields are 
empty, but this shouldn't cause any serious problems. If the 
utility refuses to read your descriptor file and aborts, check to 
see that when you transferred the description file over it did 
not pick up trailing blanks on the description items, and that 
the file position qualifier says NONE with no numbers trailing. 
You can use a regular text editor such as EDT to go over the file 
before reading it with EDIT/FDL if necessary to touch it up. If 
you don't take this approach, then you can move the record defi¬ 
nition, define a domain and define a file: DTR will create a file 
that matches the record definition. You can then look at that 
file with EDIT/FDL if you wish, or do the optimization shown 
below. If you move your disk packs FDL can probably read your 
original data file, and may also be able to do this over the 
network if you are using DECNet. 

Converting the data file from indexed to sequential on the 
PDP-11 is quite simple: the CNV utility will perform this con¬ 
version by default. Simply give the name of the indexed file on 
input, and the file name you want for the sequential file on 
output. 

Once the file description and the data file are on the 
VAX, you can populate the file with CONVERT: however, now would 
be a good time to review the file design for possible performance 
improvements. The FDL utility (EDIT/FDL) has an OPTIMIZE script 
which can make the decisions a little easier, as it will look at 
your data file and give you some information about what can be 
done to improve access. The one factor which comes up quite 
often is bucket size: on the PDP-11, bucket size is almost al¬ 
ways the smallest possible value that will hold the record size 
you are using, as larger buckets use up pool space. On the VAX, 
this is no longer a problem, and larger bucket sizes are a viable 
option. If you often retrieve records which are next to each 
other, such as retrieving a record by the primary key and then 
reading the next several records in order, then a larger bucket 
size may improve performance. If, however, you retrieve records 
scattered all over the file in no particular order, then a larger 
bucket size won't help and may hurt, but a different index struc¬ 
ture may be of benefit. If you don't know what options to take, 
use the FDL utility and let it optimize: it will usually take 
reasonable options. Once this is done, you can populate a new 
file again with CONVERT. 


Combining related domains. 

Another consideration in DTR-11 is that the data is some¬ 
times separated into several domains rather than one, to prevent 
the record definition and buffers from getting so large as to use 
up all of your pool space. When converting to VAX-DTR, you may 
want to recombine them by moving all of the individual files (and 
domain definitions) over, define a VIEW to combine them and a 
single record definition with all of the fields, and read from 
one into the other. This may be a little slow, but again, this 
will only be done once. You will then want to use FDL as descri¬ 
bed before to optimize the new combined file. 


Reports. 

For reports, the VAX-DTR works very much the same as DTR- 
11. If you have reports which are adjusted so that field breaks 
occur just at the beginning or end of a page, or are otherwise 
'finagled' to match a pre-printed form, you may find that you 
have to do a little adjustment to the lines per page or number of 
lines skipped qualifiers, but most straight forward reports will 
work with no changes. 


Expanded features in VAX-DATATRIEVE. 

Tables. 

While VAX-DTR has dictionary tables just like DTR-11, it 
also has domain tables: this allows data in a domain to also be 
accessed like a table. One field (preferably a keyed field for 
good performance) takes the place of the "left" side of the ta¬ 
ble, and another field (any one in the domain) takes the place of 
the table entry on the "right". Dictionary tables are faster for 
small tables: domain tables can be faster for large tables if 
keyed fields are used, can take the place of several tables, and 
can also be accessed as a regular domain, which makes changing 
the table the same as modifying the data in any other domain; 
therefore, tables which are modified often are easier to maintain 
as domain tables. 

Functions. 

VAX-DTR has all of the functions (MIN, MAX, TOTAL, etc.) 
that DTR-11 has, plus several more (standard deviation, and run¬ 
ning count, for example). In addition, there is a new set of 
functions of the FN$xxx family which can do things like convert 
lower case text to upper case, move sub-sections of text strings, 
format output strings, get system information, do mathematical 
operations, and many other functions. If that isn't enough, you 
can add your own functions. In many cases, things that you are 
doing, perhaps with some difficulty, with procedures or COM- 
PUTED_BY clauses may be much easier with the extra functions 
available in VAX-DTR, and a review of what you are doing may 
reveal some areas where improvements may be made. Though you 
may want to wait until your application is moved over and run¬ 
ning, this is an area where you will want to do some work quite 
soon after the move 
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No Pool Space Restrictions! 


In DTR-11, procedures are often broken into small pieces 
to conserve pool space, and more things were done in command 
files. You may consider moving more of the work into DTR proce¬ 
dures, especially when you can get large blocks into single WHILE 
or BEGIN-END blocks. This may take a little longer to compile, 
but once compiled will execute faster than separate blocks. 

In DTR-11, especially if your application was just on the 
edge of available pool space, things tended to be pared down to 
the minimum, especially in record definitions. Variable names 
were very short, edit-strings removed, etc. On the VAX, you have 
the opportunity to put more descriptive field names back in, and 
make the fields more self-documenting, put in query names, edit 
strings, and so on. Don't drop your good habits, however. Some 
users think they have infinite space on the VAX, and don't FINISH 
unused domains or RELEASE unused variables. This will cost you 
something eventually on the VAX (usually in paging), and it won't 
be as obvious as running out of pool space was in DTR-11: your 
application, or the whole system, just slowly degrades. You also 
may interfere with other users who want to access the data if you 
are keeping files open and are possibly locking records. You can 
keep domains open if you expect to use them again and save the 
time it would take to READY the domain, but when you are done 
with a domain you should FINISH it. 


Other improvements. 

All users will be happy to learn that VAX-DTR uses EDT 
when editing, rather than the built-in editor of DTR-11. If you 
have an EDTINI.EDT command file in your account, it will be used 
when you edit something in VAX-DTR; keypad and all other commands 
will work, etc. You will also notice that with the newer ver¬ 
sions of VAX-DTR, you have version numbers on definitions, so you 
can keep the old definition around until you find that the new 
version works. Users should be reminded to purge out old ver¬ 
sions regularly. 

An option available in VAX-DTR is the use of FMS or TDMS 
to have form driven screens. After your data is on the VAX and 
working, you may want to start thinking of converting some of 
your old procedures, especially if they were working like menus, 
to form driven screens. Something you do need to consider before 
you do this, however, is whether to buy FMS or TDMS: they look 
very much the same to DTR, so the choice is often determined by 
what other software you are using. Some packages will require one 
or the other, (for example, All-In-One uses FMS) while DTR can 
work with either, one at a time. 

There are various other features that are present in VAX- 
DTR (three types of concatenation rather than two, CROSS state¬ 
ments, the CHOICE statement, and all of the graphics capabilit¬ 
ies), which you will soon discover and will want to incorporate 
into your applications; but none are needed immediately for con¬ 
version, and you can wait to learn about them until after the 
problems of conversion are over. 


Wombat Magic - Part 3 1985 Fall*DECUS Symposium, 

Disneyland Hotel, Anaheim,California 

Session Chair: Bert Roseberry, U.S. Coast Guard, New Orleans, LA 
Session Editor: Donald Stern, Jr., Warner Lambert, Milford, CT 


This is the third and final in a series reporting on the Wombat 
Magic session held at the Fall symposium. As reported, the magic 
is not presented in chronological order. Where appropriate, the 
presenter's comments are quoted. 

-k-k-k-k Rowland W. Fox, Digital Interface Systems **** 

!!!!!!!!!!!!!2nd Prize Winner!!!!!!!!!!!!!!!!! 

Rowland described a supervisory application at his site which 
included group field data. 


03 GROUP1 OCCURS 10 TIMES. 
05 FIELD_AA ... 

05 FIELD AB ... 


03 GR0UP2 OCCURS 5 TIMES. 
05 FIELD_BA ... 

05 FIELD BB ... 


The problem addressed by this magic is "How do we modify the n'th 
value in a group field?" 

FOR FOO FOR GROUP2 WITH RUNNING COUNT = n 
PRINT(or MODIFY) FIELD_BB 

Operates on only the n'th occurance. 

In order to get every n'th field in a group, the following will 
work: 

FOR ALL FOO FOR GR0UP1 WITH 

FN$M0D(RUNNING COUNT,NUMBER_OCCURANCES)=n 
PRINT(or MODIFY) FIELD_AB 

**** Dana J. Schwartz, Department of Defense, 

"Moving the VAX Datatrieve Distribution Kit to Disk" **** 

"Our site has many VAX systems and, of course, every one of them 
gets Datatrieve installed. I got tired of reading those little 
floppies and cassettes in every time I wanted to install Data¬ 
trieve on a system. I have taken some other hints that I got at 
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DECUS and other places and moved the save sets that are on those 
magtapes or floppies or cassettes onto disk." 

WHY? 

Installing from a disk file is much faster and reliable than 
floppy or tape, and if you do multiple installations on systems 
with DECNET interconnections or common removable disks, the kit 
only needs to be read ONCE (!) from the distribution media. 


1. Set default to an existing directory in which distri¬ 
bution Save Sets are to be kept. 

$ SET DEFAULT SYS$SYSDEVICE:[KITS] 

2. Mount the DATATRIEVE distribution media. 

$ MOUNT /FOREIGN MTAO: 

( Use appropriate device name instead of MTAO: e.g. CSA1: ) 

3. Move the files to temporary directories. 

$ BACKUP/LOG MTAO:DTR032.A/SAVE_SET [.A] 

$ BACKUP/LOG MTAO:DTR032.B/SAVE_SET [.B] 

$ BACKUP/LOG MTAO:DTRO32.C/SAVE_SET [.C] 

$ DISMOUNT MTAO: 

( Use appropriate device name instead of MTAO: e.g. CSA1: ) 

( Use appropriate version number in Save Set name DTRxxx. e.g. 
DTRO32 is for DTR Version 3.2 ) 

( With some media, you will need to mount successive volumes when 
prompted e.g. floppies or cassettes ) 

( BACKUP will create the directories if they don't exist ) 

4. Recreate the Save Sets on disk and delete temporary 
directories. 

$ BACKUP/LOG/DELETE [.A] DTR032.A/SAVE_SET 
$ BACKUP/LOG/DELETE [.B] DTR032.B/SAVE_SET 
$ BACKUP/LOG/DELETE [.C] DTR032.C/SAVE_SET 
$ DELETE A.DIRjl 
$ DELETE B.DIRjl 
$ DELETE C.DIRjl 

3. The resulting Save Sets may be copied, backed-up, 
etc. with DCL. 

$ COPY /LOG DTRO32.* - 

N0DE12"SYSTEM pswd"::SYS$SYSDEVICE:[REMOTEKITS] 

( for installation on remote system ) 
or 

$ BACKUP/LOG/VERIFY - 
SYS$SYSDEVICE:[KITS]*.* - 
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MTAO:KITS.BCK/REWIND/DENSITY=1600 
( a Save Set of Save Sets ! ) 


$ DIRECTORY SYS$SYSDEVICE:[KITS] 
Directory SYS$SYSDEVICE:[KITS] 


CDD031.A;1 

1953 

23-MAY-1985 

11:07 

( CDD ) 

DTRO32.A;1 

567 

8-NOV-1985 

13:53 

( DATATRIEVE ) 

M 

DTRO32.B;1 

5418 

8-NOV-1985 

13:53 

DTRO32.C;1 

567 

8-N0V-1985 

13:55 

ii 

FHLP043.A;1 

504 

18-SEP-1985 

14:44 

( FORTRAN ) 

FORT043.A;1 

882 

18-SEP-1985 

14:37 

" 

GRAPH013.A;1 

189 

20-NOV-1985 

11:17 

( DECGRAPH ) 

GRAPH013.B;1 

2205 

20-NOV-1985 

11:17 

ti 

PASCAL031.A;1 

2394 

31-OCT-1985 

15:03 

( PASCAL ) 

PASSTR030.A;1 

315 

4-JUN-1985 

17:00 

" 

VAXC021.A;1 

2520 

25-OCT-1985 

13:41 

( c ) 

VAXFMS022.A;1 

1260 

8-JAN-1985 

18:04 

( FMS ) 

VAXFMS022.B;1 

819 

8-JAN-1985 

18:05 

tv 

VAXGKS010.A;1 

2394 

10-JAN-1985 

17:17 

( GKS ) 


Total of 14 files, 21987 blocks. 

6. To install, give VMSINSTAL your Save Set directory 
name instead of the distribution volume name. 


$ SET DEFAULT SYS$UPDATE: 

$ @VMSINSTAL DTRO32 SYS$SYSDEVICE:[KITS] 

or 

$ SET DEFAULT SYS$UPDATE: 

$ @VMSINSTAL 

* Where will the distribution volumes be mounted: 
SYS$SYSDEVICE:[KITS] 


NOTE: 

The files in the distribution kit ( DTRxxx.A, DTRxxx.B, and 
DTRxxx.C ) have been the same through the last several ver¬ 
sions, but you should check what is in any new kit before 
attempting this procedure on future releases. The methods I 
use are: 

a. For tape-based kits: 

$ MOUNT /FOREIGN Mxxx: 

$ BACKUP /LIST Mxxx: 

$ BACKUP /LIST Mxxx: 

until End-Of-Tape, noting the Save Set names. 
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b. For disk-based kits: 


$ MOUNT/FOREIGN Dxxx: 

$ DIR Dxxx:[000000] 

on each volume, noting DTRxxx.x names. 

**** Rowland W. Fox, Digital Interface Systems **** 

"We have a record that contains chemical analyses for about 100 
elements". Input data should be validated depending upon the 
type of analysis being performed. For example, an analysis iden¬ 
tified by CODE 1 should have moisture content data (H20) between 
0.10 and 5.12, an analysis identified by CODE 12 between 1.12 and 
4.82, etc. If the limits for each code are stored in a domain, 
the data can be verified by a table lookup. The magic here is in 
the way the VALID IF clause specifies the lookup. 

03 CODE PIC 99. 

03 H20 PIC 9.99 VALID IF 

(H20 BETWEEN ("H20_"||CODE VIA MATLOW) AND 
("H20_"||CODE VIA MATHI) 


Sample data from domain TEST_LIMITS: 

KEY LOW HIGH 

H20 1 0.10 5.12 

H20 12 1.12 4.82 


Two tables are defined: 

DEFINE TABLE MATLOW FROM TEST_LIMITS 
KEY : LOW 

END_TABLE 

DEFINE TABLE MATHI FROM TEST_LIMITS 
KEY : HIGH 

END_TABLE 

**** Wayne Jones, Digital Equipment Corp. - 

"Wine Rating System, Distribution of Ratings" **** 

Wayne described a rather unique Datatrieve application that a 
colleague developed after making a trip through the Napa Valley 
tasting and rating the various wines of the area. The domain 
contained the data including such items as the name of the vine¬ 
yard, the type of wine, and a rating from 0 to 9. 

DEFINE DOMAIN WINES USING WINES_REC ON WINES.DAT; 

DEFINE RECORD WINES REC 


03 VINEYARD ... 

03 TYPE ... 

03 RATING USAGE INTEGER. 


The question of whether the assigned ratings followed some sort 
of a standard statistical distribution came up. In order to get 
a frequency of occurrence the following was done to get a count 
of all the unique occurrences of rating. 

DEFINE F00 PIC 9 COMPUTED BY RATING. 

READY WINES 

FIND WINES 

SUM 1 BY F00 


3 2 

3 4 

4 6 
4 9 


The problem with this is that ratings of exactly 3 will produce 
one count, ratings of 3.5 another, and so on. In order to over¬ 
come this limitation the following was done. 

DEFINE F00 COMPUTED BY FORMAT(RATING) USING 9. 

SUM 1 BY FOO 


3 6 

4 15 


In this case values between 3 and 4 are summed on one line, bet¬ 
ween 4 and 5 on the next, and so forth. 

**** ji m McMillan, Arizona Supreme Court - 

"CHOICE in the Report Writer" **** 

In his presentation, Jim reminded us that it is perfectly valid 
to use the CHOICE statement with the Datatrieve Report Writer. 

REPORT YACHTS 

PRINT CHOICE 

LOA GT 40 THEN "Papa Boat" 

LOA BETWEEN 25 AND 39 THEN "Mama Boat" 
ELSE "Baby Boat" 

END_CHOICE, PRICE, MODEL 
END REPORT 
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**** Leonard Herzmark, Maricopa County Health Dept, Phoenix, AZ - 
"Air Pollution Control Application" **** 

Leonard described an application which keeps track of air pollu¬ 
tion control records. The database primarily consists of five 
domains: ANNUAL - containing records with data about particular 
plants, EMISSIONS - containing records with data about the mater¬ 
ial in process and the particular emission control devices, 
EQUIPMENT - containing records with data about non-electric 
equipment such as incinerators and boilers, ELECTRIC - containing 
records with data about electric equipment, and COMMENTS - con¬ 
taining records with comment data. The data in the five domains 
are linked together using a common field called PNUM. What is 
needed is a report which is given to the pollution control ins¬ 
pector when he goes to inspect a plant. The report is produced 
by the following... 

READY ANNUAL SHARED 
READY EMISSIONS SHARED 
READY EQUIPMENT SHARED 
READY ELECTRIC SHARED 
READY COMMENTS SHARED 

DECLARE VPNUM PIC 9(7). 

VPNUM = *."Plant number" 

FOR ANNUAL WITH PNUM = VPNUM 
BEGIN 

PRINT <print list> 

PRINT <print list> of EQUIPMENT WITH PNUM=VPNUM 
PRINT <print list> of ELECTRIC WITH PNUM=VPNUM 
PRINT <print list> of EMISSIONS WITH PNUM=VPNUM 
PRINT <print list> of COMMENTS WITH PNUM=VPNUM 

END 

**** Joe H. Gallagher - 

"Most Complicated Datatrieve Startup File" **** 

Joe described an application which he developed for a large medi¬ 
cal facility. Part of the application was to keep track of a 
variety of patient skin tests. The patch test is applied and 
then read 24 and 48 hours later. The data is stored with an 

occurs clause which is redefined. The specific record defini¬ 

tion, in this case, is as follows. 

! Nutritional Assessment Record Definition 
f 

Define record na-record using 
01 na-rec. 

!patient demographic and 

lother medical information (not shown) 

03 tricep pic 99. 

03 albumin pic 9V9. 

03 transferrin pic 999. 

03 ptests_done pic x 

valid if ptests_done="Y","N"," ". 

03 patch__tests. 
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05 cani24 pic 99. 

05 cani48 pic 99. 

05 trii24 * pic 99. 

05 trii48 pic 99. 

05 ppdi24 pic 99. 

05 ppdi48 pic 99. 

05 mumi24 pic 99. 

05 mum48 pic 99. 

03 p-test redefines patch_tests. 
05 p-tests occurs 4 times. 
07 test24 pic 99. 

07 test48 pic 99. 


A nutritional index for a patient is computed by a formula which 
uses these values together with the number of responses to a test 
and the magnitude of the response. The following commands are 
placed in the Datatrieve startup file to produce the index. 

! DATATRIEVE startup file DTRSTART.COM 

f 

set plots cdd$top.dtr$lib.plots 

i 

! Find the greater of test24 and test48; 

! 99 represents a missing value. 

! If both tests do not exist then assign 
! 99 to x_maxtest to indicate this. 

! 

declare x_maxtest computed by 
choice of 

test24 It 99 and test48 It 99 and test24 gt test48 
then test24 

test24 It 99 and test48 It 99 and test48 ge test24 
then test48 
else 99 
end_choice. 

! 

!Compute the number of complete tests 
j 

declare x_ntst computed by count of p_tests with 
x_maxtest ne 99. Inumber of tests 

! Compute the number of positive tests; if the tested 
! value is less than 5 then the test is negative 

declare x_npos computed by count of p_tests with 
x_maxtest bt 5 and 98. 

! Compute the number of incomplete or missing tests 

declare x_pflag computed by count of p_tests with 
maxtest eq 99. 

! 

! Compute a weighting factor 
declare x_spoint computed by 

(count of p_tests with x_maxtest bt 1 and 5) + 
2*(count of p_tests with x_maxtest bt 5.0001 and 98). 
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Compute the nutritional index 


declare x_pni pic s999 computed by 
choice of 

(x_pflag eq 0 and transferrin gt 0 and ptests_done 
eq i") then (158 - 16.6*albumin - 0.78~tricep - 
0.20*transferrin - 5.8*x_spoint) 
else -999 
end_choice. 

! 

! Now make the nutritional index suitable for 
! reporting 
f 

declare xx_pni pic xxx computed by 
choice of 

( x_pni eq -999) then " " 

( x_pni gt 100 ) then "100" 

( x_pni It 0 ) then " 0" 

( x_pni bt 10 and 99) then " "|x_pni 

else " "|x_pni 

end_choice. 

When manipulating the patient data, therefore, the nutritional 
index (xx_pni) is available. 

**** B.Z. Lederman, Greenberg Bros., NY - 
"Gotcha" **** 

"This is one that I've done before but ifs worth seeing it again. 
What's wrong with this field?" 

01 RECORD. 

10 DESC PIC X(10) QUERY_HEADER "Description". 

"This works for about a month until the first time someone 
says ..." 

"PRINT domain SORTED By DESC DESC" 

**** Phil Naecker, J.M. Montgomery - 
"DATATRIEVE Syntax" **** 

"You can type the following command into DATATRIEVE and IT WILL 
WORK!" 

DTR> FIND FIND WITH WITH EQUAL EQUAL SORTED SORTED 
[enhancement from audience] 

DTR> FIND FIND WITH WITH EQUAL EQUAL SORTED SORTED OVER 
OVER 

**************** End of Fall 85 Wombat Magic **************** 

See y'all in Dallas for Spring 86 Wombat Magic... 


AT THE FALL DECUS IN ANAHEIM, THE ATTENDEES EXPECTED THIS . . . 
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Report on the GAPSIG GKS Working Group Pre-Symposium Seminars on Graphics 

Jim Flatten January 11. 1986 


For some time. I have been working to obtain 
permission from Randy Simons of SANDIA 
to submit his implementation of the Graph¬ 
ics Kernal System (GKS) graphics package 
to DECUS. I finally got permission to do 
so about one month before the Fall DECUS 
Symposium in Anaheim. 

This package is a level ma implementation of 
the GKS standard recently approved by both 
ANSI and ISO. Level ma is the lowest im¬ 
plementation level of the GKS standard. It 
provides no input functions and no segment 
or bundle support. 

The implementation is written in C and was 
originally done on a VAX running ULTRIX. 
The package conforms to the May 1985 ver¬ 
sion of the C binding to GKS. This binding 
is not yet an official standard and will not be 
until a standard for the C language itself is 
approved. 

My interest in this package comes from a 
need in my own work at Ames Laboratory to 
provide standard graphics packages for use 
on small computers (LSI 11/23). I want to 
pursue the conversion of this package to RT- 
11. and in fact I have already done this for an 
earlier version of the same package. 

As a SIG project, there are four areas where 
we can enhance the package. 

1. Migrate to other operating systems 

2. Add new device drivers 

3. Add new bindings 

4. Add functionality 

We are interested in pursuing the first three 


items now and the fourth at a later time. 

We would like to see the package imple¬ 
mented with the DECUS C compiler so that 
it can be made available to DECUS members 
without requiring them to buy a C compiler. 
This will mean however that we will need to 
use the alternate, non-standard C binding, 
because DECUS C will not support the long 
names required by the C binding, nor will it 
support passing structures by value. 

At the Anaheim meeting, we solicited inter¬ 
ested people to work on this graphics pack¬ 
age. Currently we have about twenty people 
on our mailing list who have indicated that 
they have some interest. If you are inter¬ 
ested in participating in this project, contact 
me or Mike McPherson our Tape Coordina¬ 
tor, at one of the following addresses: 

Jim Flatten 
304 Metallurgy 
Ames Laboratory 
Ames, IA 50011 

or 

Mike McPherson 
Michigan State University 
269 Engineering Bldg 
East Lansing, Ml 48824 

Mike can make copies of the tape in VMS and 
TAR formats. I am working on setting up an 
account on our VAX system at Ames Labo¬ 
ratory so that you can dial in and down load 
the code using KERMIT. We will be sending 
out more details about how to participate, 
directly to the people on our mailing list. 


William Kramer 

The GAPSIG is proud to present two Pre- 
Symposium Seminars at the Dallas Sym¬ 
posia. These seminars are day long intensive 
sessions held on the Sunday before the sym¬ 
posia. The are designed to investigate topics 
in greater detail than is allowed through indi¬ 
vidual symposia seminars. 

The first seminar is entitled ‘Graphics on the 
VAXstation”. presented by two DEC engi¬ 
neers. Peter George the Workstation Product 
Manager and Keith Cumeford a member of 
the GKS Development Team at DEC. This 
seminar will explain the use of the two major 
graphics interfaces on the VAXstation. GKS 
and UIS. GKS is the international standard 
implementation which is available on the en¬ 
tire VAX family of computers and worksta¬ 
tions. It is used to develop sophisticated 
graphics applications which are device inde¬ 
pendent and portable. UIS is the VAXstation 
specific interface which allows device opera¬ 
tions such as window control and pixel opera¬ 
tions. It is only available on VAXstation prod¬ 
ucts. This seminar will explain how and when 
these different interfaces should be used to 
develop graphics applications. 

Our other seminar offering is "Introduction to 
Interactive Graphics". Bijoy Misra. a Com¬ 
puter Scientist at the Harvard-Smithsonian 
Center for Astrophysics is the presenter. Dr. 
Misra has been involved graphics program¬ 
mer and designer for over 15 years and he 


is now involved in the development of a new 
graphics interface language for doing interac¬ 
tive scientific graphics. This seminar will be 
important to people who are developing ap¬ 
plications on VAXstations. 

This seminar will be an introduction to the 
concepts of interactive computer graphics. It 
will review the current technology and with 
a review of viewport mapping and 2 and 3D 
transformations. Other topics will be projec¬ 
tion algorithms, image transformations, and 
hidden line and surface removal. Concerns 
related to color and shading will be explored 
and the proper way to design graphics sys¬ 
tems will be developed. Overall this seminar 
will be a great chance to get up to speed in 
advanced computer graphics and to learn the 
basics of designing interactive graphics sys¬ 
tems. 

You can sign up for either of these seminars 
when you mail in your registration form for 
the DECUS symposia. Remember that you 
must register in advance for the seminars, 
and that walk-in registration can not counted 
on. The seminars will have handout material. 
These seminars are new this time, but from 
past experience, it is clear the people who 
attend pre-symposium seminars have found 
them very rewarding. Attending these either 
one of these seminars will be very benefical 
to you. 
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Report on the 21 Meeting o-f X3H3 
Computer Graphics 
Jim Flatten, DECUS Representative 
February 9, 1986 


The 21st meeting o-f the X3H3 technical committee on 
computer graphics met in San Diego California during the 
Meek of February 3-7, 1986. The first three days were 

devoted to task group meetings. The plenary session was 
Thursday and Friday. 

X3H3 is broken into five task groups and an Ad Hoc 
group, soon to become a sixth task group. The task groups 
and their work assignments are: 


X3H3.1 - The Programmers Hierarchical Interactive 
Graphics System (PHIGS) 

X3H3.2 - Formal Description, Validation and Testing 
Group (FDVT) 

X3H3.3 - Computer Graphics Interface (CGI) / Computer 
Graphics Metafile (CGM) 

X3H3.4 - Language Bindings 

X3H3.5 - Graphical Kernal System (GKS) 

Ad Hoc - Windows Ad Hoc Task Group (X3H3.6) 


During the plenary meeting, each task group reported on the 
status of their work. 


I participated in the X3H3.1 (PHIGS) task group 

meetings. We worked on several items during these sessions, 
including: 

1. A review of the US comments to the PHIGS ISO DP 
draft document. 

2. A review of the latest Product Description 

Exchange System (PDES) document and its 

relationship to PHIGS. This work is being 
sponsored by the Y14.26 committee although the 
most of the work is done by the National Bureau of 
Standards. This work is a follow-on to the earlier 
IGES standard. The current document differentiates 
between model description and presentation 
information. X3H3.1 reviewed the presentation 
entities draft and will respond to the PDES 
committee. X3H3 feels that it is important for 
PDES to be upward compatible from the CGM and the 
PHIGS archive file. X3H3 is currently seeking a 
new liason to Y14.26. 


3. Preparation of the US delegates to the Frankfort 
meeting of ISO TC97/SC21 /WG2 in March. The X3H3 
goals for the Frankfort meeting are to resolve 
currently unresolved issues, to produce reference 
models and educate people about PHIGS and to begin 
a redraft of the PHIGS document. Jurgen Bettels of 
the Swiss delegation to ISO has been solicited to 
be the rapporteur for the ISO PHIGS effort. He 
will replace Terry Hewitt of the British Standards 
Institute (BSI) who recently retired. 

4. Implementors of PHIGS (Megatek, IBM and RPI) 

discussed their implementations and problems they 
have encountered in implementing PHIGS. A 

reception was held on Tuesday evening, February 4, 
at which Megatek demonstrated their implementation 
of PHIGS. 

5. We updated PHIGS reference models and prepared 
them for input to the X3H3.2 task group. 

PHIGS is currently out for public review in the United 
States and is also being considered for DP status in ISO. 
Comments on the proposed PHIGS standard (ANSI document 
X3.144) must be made by March 22, 1986. 


X3H3.2 (FORMAL DESCRIPTION, VALIDATION AND TESTING) 

NBS has agreed to act as the registration authority for 
graphical items for ISO. The procedures are in place for 
registration of Generalized Drawing Primitives (GDPs) and 
Escapes. Language bindings for these items are likely to be 
a problem however. The items can be submitted by 
organizations that are unlikely to be familiar wirh X3H3 
binding procedures. Preliminary indications are that binding 
of GDPs and ESCAPES is likely to be as difficult as binding 
GKS functions originally. Futhermore, the rules for 
developing bindings are not documented. Submitting 
organizations are unlikely to have the neccessary expertise 
and NBS doesn't have the man power. The problem has not been 
resolved yet. 

NBS also has a hand in the validation of GKS 
implementations. They have computer routines designed to 
test GKS implementations. New routines have recently been 
received that will test levels of GKS up to 2B. NBS is also 
looking for volunteers to help develope validation routines 
for GKS, GKS—3D, PHIGS and CGI and convert existing routines 
to other languages. 

NBS has the power to develope Federal Information 
Processing Standards (FIPS). GKS will become a FIPS soon and 
it is anticipated that other ANSI graphics standards will 
follow. 
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X3H3.3 (CGM/CGI) 


The Computer Graphics Metafile (CGM) Standard will soon 
become the second graphics standard produced by the X3H3 
committee. A ballot is currently under consideration in X3 
to forward the CGM Standard, ANSI document X3.122, to the 
Board of Standards Review (BSR). One negative vote (DEC) is 
anticipated which will require extra processing depending on 
whether the associated comments contain new technical 
content or not. It is anticipated that the CGM will become 
an American National Standard in July or August of 1986. 

The CGM is also being processed as an international 
standard (DIS 8632/1-4). A ballot to consider the ISO CGM 
document begins around February 15, 1986 and will end in 
August, 1986. Comments orv the document will be processed at 
the September meeting of SC21/WG2. The final CGM text is 
expected in October and in November the IS text will be 
completed. It is expected that the CGM will be published as 
an ISO standard in June, 1987. 

The Computer Graphics Interface (CGI) is being 
processed simultaneously by ANSI and ISO. At the San Diego 
meeting X3H3.3 prepared the U.S. position on CGI for the 
upcoming ISO meeting in Frankfort Germany. They also 
reviewed the U.S. comments to the initial draft of the ISO 
document. 


X3H3.4 (LANGUAGE BINDINGS) 

The functional specifications (semantics) for the 
standards being processed by X3H3 are "bound" to various 
programming languages. Language bindings specify the syntax 
for graphics functions when working in a particular 
programming language. X3H3.4 is working on language bindings 
for GKS, GKS-3D, PHIGS and CGI. Language bindings are being 
standardized in several languages including FORTRAN, Ada , 
COBOL, PL/I, Pascal and C. 

Since the last meeting, SD3' s (an SD3 is an ANSI 
project proposal) have been approved for bindings of GKS-3D 
to Ada , FORTRAN, Pascal and C. SD3's were approved to begin 
bindings of the CGI to FORTRAN and C. 

The status of various GKS bindings, both in ANSI and 
ISO were presented. The status is: 


ANSI 

FORTRAN This binding is now an American National Standard 


ADA The binding is expected to go out for public 

review in March, 1986. 

C A letter ballot will be circulated to X3H3 to 
forward the binding to X3 for public review. The 
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binding would be out for public review around the 
first of April. 

PASCAL A letter ballot will be circulated to X3H3 to 
forward the binding to X3 for public review. The 
binding would be out for public review beginning 
in September, 1986. 


ISO 

FORTRAN The document is currentlu out for DIS balloting. 
It is identical to the ANSI document. 

ADA The document is out for a second DP ballot. The 
U.S. voted to approve the document. 

C A DP ballot on the C binding should begin about 
April 1, 1986. 

PASCAL A DIS ballot for this binding is currently 
underway. The U.S. has some major concerns about 
the binding and will vote NO on the document. 

Work is underway on various PHIGS bindings. The status 
of these bindings follows. 


ANSI 

FORTRAN The PHIGS FORTRAN binding will go out for public 
review in March, 1986. 

C The PHIGS C binding will be circulated for letter 
ballot in X3H3 in July to be followed by an 
anticipated public review beginning in November, 
1986. 

ADA The PHIGS ADA binding will be circulated for 
letter ballot in X3H3 in July to be followed by an 
anticipated public review beginning in November, 
1986. 

PASCAL The first draft of the PHIGS PASCAL binding should 
be ready in October. An SD3 for this work will be 
voted at the June meeting of X3H3. 


ISO 

FORTRAN The document will be sumbitted to SC21/WG2 in 

September for working draft distribution. 

C The document will be submitted to SC21/WG2 in 

September for working draft distribution. 
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ADA No current activity 


PASCAL No current activity. 

Work is underway on various CGI bindings. The status o-f 
these bindings follows. 


FORTRAN A letter ballot will be circulated to X3H3 in July 
on this binding. 

C A letter ballot will be circulated to X3H3 in July 
on this binding. 

ADA Work on this binding is just beginning. 

PASCAL No current activity. 


ISO 

FORTRAN The document will be sumbitted to SC21/WG2 in 

September for working draft distribution. 

C The document will be submitted to SC21/WG2 in 

September for working draft distribution. 

ADA No current activity 

PASCAL No current activity. 


X3H3.5 (GKS) 

The ANSI version of GKS has been published including 
the FORTRAN binding. X3H3.5 is currently working on the 
follow-on standard for GKS, namely the three dimensional 
standard GKS—3D. GKS—3D is expected to go out for a three 
month letter ballot this summer. The letter ballot period is 
expected to end about September 15, 1986. GKS—3D will also 
go out for an ISO DIS ballot around August 1, 1986. 

ACM voted no with comment on the project proposal for 
GKS—3D. They indicated that they believe GKS is a poor model 
for developing a family of graphics standards. An X3H3 vote 
was made on the response to the ACM comment. Essentially 
X3H3 responded that they think GKS—3D is an important 
extension to GKS, but GKS is already an ISO and ANSI 
standard and the functionality of GKS is not at issue. The 
response was approved by a vote of 62-0-1. 

The result of the letter ballot to forward GKS-3D for 
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public review was 49-18-2. As a result of this letter ballot 
it was determined that the document sent out for public 
review will not be a delta document as it currently is, but 
a complete document that will stand on its own. 

There was some discussion over whether GKS and GKS—3D 
fit together or not. It isn't clear whether GKS—3D will be a 
level of GKS or not and some people felt that if they become 
separate standards they will eventually diverge from one 
another. The question was deferred to an X3H3 letter ballot. 

WINDOWS 

The ad-hoc windows task group is still an ad-hoc group 
due to some administrative problems. It is anticipated the 
this group will become X3H3.6 at the next meeting of X3H3. 
It was reported that X3 has approved the project proposal 
for the group. An aggresive schedule was presented which 
would see the result of this committee's work available for 
public review in the Spring of 1988. 


LIASON TO X3V1 

Frank Dawson of McDonnell Douglas is the X3H3 liason to 
the committee working on text and graphics X3V1. He reported 
on the work currently being done by that committee. He 
indicated that there appears to be two constituencies 
represented on X3V1. One supports the use of 0DA/0DIF 
(Office Document Architecture/Office Document Interchange 
Format) and the other wants SGML (Standard Generalized 
Markup Language) and SDIF (SMGL Document Interchange Format) 
to be used as a standard for ducument layout and 
interchange. 

He also introduced the committee to MAP/TOP 
(Manufacturing Automation Protocol/Technical Office 
Protocol). He said that the MAP/TOP effort is being 
sponsored as an activity under the Society of Mechanical 
Engineers (SME) . He emphasized that this is a user group, 
not a technical standards committee, and is made up of 
managers and policy makers. Their idea is to speed up and 
influence the standard development process. They are using 
the ISO Open Systems Interconnection (OSI) model as a basis. 
A demonstration of TOP is planned by June 1987 similar to 
the demonstration of MAP at AUTOFACT recently. 


FUTURE MEETINGS 

Future meetings of X3H3 are scheduled for June 2-6, 
1986 in Minneapolis MN, and October 12-16, 1986 in Saratoga 
NY. Plans for meetings after Saratoga have not been 
completed at this time. 
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Graphics Application SIG 
Activity in Dallas 


The theme topic for the Graphics Applications SIG at Dallas is 
Graphics on Workstations and we have an interesting variety 
of sessions scheduled for this Symposium around this theme 
Besides the sessions on Workstations, we will have sessions on 
graphics standards, GKS products, graphics on PC and inter 
active graphica The Symposium will be preceded by two pre¬ 
symposium seminars on introduction to computer graphics and 
graphics on VAXstations, to be held on Sunday before the 
Symposium. 

The keynote session will be delivered by Mr. Tom Wright of 
ISSCO on Monday afternoon. Mr. Wright, with his long involve¬ 
ment in developing graphics software is ideally suited to dis¬ 
cuss the new orientation for graphics on Workstationa These 
sessions would be followed by sessions on Digital’s plan on 
Workstations and VAXstation internals and graphics pro¬ 
gramming interface Other sessions on VAXstations include 
device driver software performance guidelines and window 
management system. 

Several sessions on interactive graphics, user interface and 
color graphics are scheduled on Tuesday. These will include 
sessions on human interface methods, engineering graphics 
generator, windowing designs and the proposed standard 
Sessions on color graphics will be done by engineers from Tek¬ 
tronix and will include sessions on data analysis and color 


graphics terminals. On Wednesday, we have scheduled sessions 
related to VAX GKS and GKS-related products. These will 
include sessions on GKS programming GKS implementation, 
advanced concepts and nonstandard devices. There will be also 
sessions on GKS standards update and the proposed GKS-3D 
standards. The hardcopy related sessions are scheduled on 
Thursday. They include sessions on Postscript, VAXstation 
hardcopy output system, merging graphics and text and a 
tutorial on font design. Finally, the sessions on graphics on per¬ 
sonal computers and sessions on Computer Assisted Drawing 
(CAD) and Computer Assisted Instruction (CAI) are scheduled 
on Friday. All sessions are designed to leave time for discussion 
and answer questions from the audience A special session 
called Graphics Users’ Forum is scheduled Wednesday and 
Graphics Question and Answer session is scheduled on Thursday. 

Besides the sessions discussed above there will be a camp¬ 
ground to provide hands-on experience on using VAXstations 
and opportunity of discussing various graphics problems with 
the Digital engineers and members of the Graphics SIG Steer¬ 
ing Committee With strong emphasis on VAXstations and 
hardware and software concepts, the Dallas Symposium will be 
the most informative for graphics enthusiasts. We hope you can 
make time to attend the Symposium and invite you all to join us 
in the Symposium activities. 
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Division of Medical Physics 
Department of Radiation Therapy 
University of Pennsylvania 
Philadelphia, Pennsylvania 
25 February 1986 

Dear IAS Enthusiast, 

Congratulations are in order. Michael Garcia and his wife had a 
son, Matthew, last month. Mike is one of the IAS Development Team 
in Maynard and currently also deeply involved in answering some of 
the SPRs we've been sending. I'm sure that I speak for all of us 
in wishing Mike and his family well. 

There is a group of RSX-llM people who are interested in collecting 
old distributions of RSX. Since we share a common heritage, I 
thought that one or more of you might have some in your collection. 
RSX-11A and RSX-llB are in particular demand. I have forgotten the 
details of the quest, but I recall that there was some activity in 
"bringing them up!" Please call me to refer you to this group of 
RSX historians. 

Ted Smith, my partner, was trying to bring up DECnet on IAS V3.2B. 
He discovered one of those things that take a bunch of time that 
"everyone" knows about. It is time to air it again. The 
taskbuilder aborted when trying to build one of the DECnet 
components. I forget the message and the component - I think that 
it doesn't matter. Ted and I spent a LOT of time trying to alter 
the front end parameters of the DECnet 'build' file to no avail. 

I Telephone support was unable to help - "It builds here OK." A very 
good friend provided the answer: There's a bug in TKB that's been 
there since IAS branched off from RSX. It has to do with the way 
TKB divides up the free space inside itself - if "something" 
happens (I am fuzzy on this point) TKB aborts. The answer is to 
INStall TKB with an iNCrement of 15000. The real answer is to 
adjust the increment so that it doesn't abort! In the case of 
DECnet the value is 15000. No joke, when we did it DECnet built 
just fine. Talking to telephone support later we discovered that 
TKB is installed with an increment of 15000 on their machine. 

I have included a copy of my DEC Professional article on MACRO-11 
f from the May 1984 issue. The Editor and the Publisher of the DEC 
Professional have graciously permitted me to reprint it at my 
request. It is something that seems to generate some continuing 
interest and that particular article is now hard to find. I hope 
you agree that it should be included in this newsletter. 

1 Yesterday I went to DECworld. I got up very early and was there 
= when the doors opened so that I could sit front row center when 
1 Kenneth Olsen made the opening address. He is very impressive in 
person. 

DECworld is not aimed at me and I was disappointed. I was in awe 
of the magnitude of the organization and the display. Clearly the 
"Exhibit Area" at DECUS Symposia are "small potatoes" when compared 


to DECworld. That was not the problem. They were selling 
"Solutions" - not iron. I can not tell whether that is a real 
shift for Digital - or just my first DECworld. I got an eerie 
sensation that Digital was making the first overt move that would 
squarely place them against IBM. Digital is going to win. 

The disappointment derived from my feeling that the Iron Works at 
146 Main Street, next to the Assabet River, is losing its interest 
in me, the little guy that might buy a computer every decade and 
try to keep it going in the interim. Everything is VAX, as if you 
didn't know. I went to a PDP-11 Seminar: PDP-lls: The Commitment 
Continues. The speakers were Lucien R. Philippon, MSD Systems 
Product Management and Bill Andrus, Manager, Software Product 
Managers, Micro Systems Development. Micro Systems Development 
(MSD) appears to "own" all PDP-lls and the microVAX. Mr. 
Philippon was the hardware person and Mr. Andrus was the software 
person. They had a very nice presentation that they admitted was 
well rehearsed in front of the Digital censors. I felt pretty good 
about the future of the PDP-11 even though he didn't mention IAS in 
the list of PDP-11 software that they were committed to. Their 
premise was that there will be PDP-lls as long as Digital can make 
money from them - I have no problem with that. 

During the Q&A they said that while no one knows for sure how many 
PDP-lls were out there, since it was hard to know whether to count 
chip sets, etc. - the "official" number is "over 600,00 PDP-lls 
have been shipped." And there were about 30,000 shipped last year. 
Of the §6,700,000,000 that Digital grossed last year about 20% is 
PDP-11 business. The margin was not mentioned, so it was not 
possible to determine whether they made money on the PDP-11 last 
year! I guess that we're OK for this year at least. 

There were several questions from the people who buy "boards" and 
put them into something they sell that contains a PDP-11. I didn't 
understand the issues, but the questioners didn't like the answers 
- Digital appeared to be changing the rules on them after they had 
made a big investment. Clearly an issue of interest. 

Finally I asked about "retiring" software. Would they do as they 
have done with DBMS-11 - just stop support, no sources, no 
recourse, just drop dead? Mr. Andrus appeared to be unable to say 
what came to his mind - it was a nasty question. What he did say 
was "there are corporate software retirement guidelines." when I 
asked that he be more specific he said that he didn't know what 
they were. I asked if he would get them for me and he said, "Yes." 
I will share them with you if possible. 

So, while the session started on a positive note, by the end I was 
disquieted again. 

Mr. Philippon mentioned that IAS and RSTS do not run on an 11/84 
with the Floating Point Processor chip. He mentioned the reason. 
The problem has been fixed, however, and they have ll/84s running 
IAS and RSTS with the FPP chip he said. I got the feeling that 
they had not been distributed yet. 
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The reason for being in Boston was the SIG Council meeting in 
Marlboro on Friday, Saturday and Sunday. For those of you who have 
avoided my little DECUS structure tutorials, the SIG Council is 
made up of the Chairmen of all the SIGS. In addition we have a 
Chairman, Sandy Krueger, and Vice Chairman (Jim Welbourne) who 
represent our group on the Management Council, the group that 
really runs DECUS. there are the leaders of some sub groups of the 
SIG the Product Development Committee (responsible for dealing 
directly with Digital on 'futures'). After a long time and after a 
massive effort on the part of Stuart Lewis, the Council approved 
the formation of the Business Applications SIG. 

I have recently communicated with Carol Chorlton, whom many of you 
remember as the girl from Reading who pronounced "scheduler" so 
well. It is her memory that February 1976 was the "first ship" 
date for IAS. She thinks it was Vl.O. I have been unable to 
confirm the date, but she's been right about so many of the IAS 
technical details that we should celebrate: Happy Birthday IAS! 
10 and growing. 

It is still Winter in Philadelphia; the Groundhog (or woodchuck) on 
Groundhog's Day (February 2nd) predicted that "Spring is just 
around the corner." Fortunately, I like Winter! May Spring (and 
this newsletter) find you well, 

Bob Curley 

IAS SIG Chairman 


Letter from the Editor 


Our Cross pen saga continues. We have started the process of 
ordering more pens, and have let Decus Central try to find the 
others. I hope they should be available by Dallas. (If the 
paperwork is moved along). So if you have been holding up your 
articles and waiting for the availability of these pens, wait no 
longer! Anything published in 1986 will count. 

By the time you read this the Board of Directors election should be 
in full swing. I would have liked to make a very strong 
endorsement, but I am not able to because of Decus Policy: "Any 
group within DECUS that wishes to comment on the Board of Directors 
election in its publications) must provide an opportunity for all 
candidates to make a statement in the same issue so that all 
candidates will have an equal opportunity for visibility." 
"Candidates or other leaders who violate this policy will be held 
in violation of the DECUS 'Statement of Computing Ethics'." 

I am for fairness as much as the next guy, and being held in 
violation of the "Statement of Computing Ethics" (as preposterous 
as it sounds) must be a real bad trip. Therefore I figuratively 
will bite my tongue on what I might want to say on the election. 
However, I will ask you to vote, and to borrow a quote from Doug 
Boher's area of the country: "Vote early and vote often." It 
appears that if you only favor one candidate that you should only 
vote for that one, voting for more will only dilute the effect. 


The DeVIAS Letter needs your help to be an effective forum for 
issues related to IAS. Please send all contributions to: 


John Roman 

McDonnell Douglas Corp. - Dept. N436 
600 McDonnell Blvd. 
Hazelwood, Missouri 63042 
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IAS Users in Silicon Valley / San Fransisco 


Thank You, Ken Guralnik 


I am looking for names and phone numbers of people in the Silicon 
Valley / San Fransisco Bay area that I could contact regarding IAS 
questions. Attending DECUS gave me the opportunity to have my 
questions answered, but there are always more that pop up as I 
learn how IAS works. 


Dena Shelton 
Systems Industries 
1855 Barber Lane, M/S 401 
Milpitas, CA 95035 
(408)942-1212 Ext. 259 



Shown is Bob Curley (left) IAS Sig Chair presenting a plaque 
(below) to Ken Guralnik for his contributions to the IAS SIG 
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Meet Your Steering Committee 




Mike Robitaille 
Librarian 


Skip Stanfield 
Symposium Coordinator 


Mike Reilly 
DEC Counterpart 
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John Roman 
Editor DeVIAS Letter 



Bob Mack 
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Kerry Wyckoff 
Member-at-large 
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Getting Started with MACRO-11 


Robert F. Curley 
Department of Radiation Therapy 
University of Pennsylvania 
Philadelphia, Pennsylvania 

I think that most of us become fluent in a programming language by 
using it, not by studying it in a text book. MACRO-11 is no 
different. Writing the first program in the PDP-11 Assembly 
Language is more difficult than most languages because there is no 
single reference. Most places that you look contain no examples 
that work. There are very few simple, getting started programs. 
There are many device drivers and examples of that ilk - too hard 
to be useful to a beginner. 

The I/O is the real problem, the assembly language itself is pretty 
well documented. By restricting ourselves to two "black boxes" or 
"system macros" or "system directives" we can get quite a way into 
the most useful second language for PDP-11 high level language 
programmers. A system directive is a request of the operating 
system for some service. In our case we'll ask for the operating 
system to move a character from our programming space out to our 
terminal. And, we'll notify .the operating system that we're done 
with the program. The directives that I find least intimidating 
are from RT-11: ".TTYOU" and ".EXIT". To use these two requests 
for system services on other systems it is necessary to translate 
them into the correct form for that system. We'll emulate .TTYOU 
and .EXIT under several operating systems {1}. 

Create your first program in a file ONE.MAC{3}: 

.TITLE ONE 
RED: .WORD 101 

BLUE: MOV RED,R0 

.TTYOU 
.EXIT 

.END BLUE 

This is your first program. You may immediately assemble it and 
link ("taskbuild" if you speak RSX) it and execute it.{2} 

The program prints an upper case letter A on your terminal. The 
grace with which it happens varies with operating system. Some 
perform a carriage return, line feed sequence before your program 
starts executing; and another as the program exits. Some operating 
systems allow the 'A' to be printed over the prompt on the left 
margin. If you have one of these, you might wish to modify your 
program to print a carriage return, line feed sequence before and 
after the main part of your program. For example, create the file 
TWO.MAC: 

.TITLE TWO 

PINK: .WORD 101 

CR: .WORD 15 
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LF: 

.WORD 

12 

START: 

MOV 
.TTYOU 

CR, R0 


MOV 
.TTYOU 

LF,R0 


MOV 
.TTYOU 

PINK,R0 


MOV 
.TTYOU 

CR, R0 


MOV 
.TTYOU 
.EXIT 

LF, R0 


.END 

START 


Program TWO prints five characters on your terminal: carriage 
return, line feed, upper case A, carriage return, line feed. 

A discussion of the components of Program ONE and TWO is in order. 
The syntax of MACRO-11 is simple: four fields, label, operation 
code (opcode), operands, comments. Labels begin the line and are 
terminated by a colon. Opcodes are next, terminated by a 
delimiter: space, tab, carriage-return. Operands next, separated 
by commas if there are more than one. I'll ignore comments. I use 
these rules: a label goes at the left margin, a tab, the opcode, a 
tab, the operands. No label? Tab to the opcode field. There are 
more elaborate schemes, this will get you started. 

The '.TITLE' is an example of a class of program components called 
"assembler directives". It is a command (request) to the 
assembler, evaluated or executed at assembly time. In this case, 
the '.TITLE' tells the assembler to call this program 'ONE'. The 
use of this naming varies with your operating system but the 
assembler uses it to title the listings and the linker 
(taskbuilder) uses it on the map listing. For the beginner 
programmer it performs no useful function - if you leave it out the 
program works the same. I recommend the use of the .TITLE 
directive as a good habit for later benefit! 

The next line, starting with 'RED:' asks the assembler to reserve a 
word of memory (the '.WORD' assembler directive), call that word 
'RED' and start the program with RED containing the octal value 
101. Unlike most high level languages MACRO-11 associates two 
values with a memory location: the address and the contents. Here 
the address is 'RED' and the contents, 101. The value, 101, is 
assumed to be octal? as are all numeric constants unless you 
explicitly notify the assembler otherwise. 

The next line, starting with 'BLUE:', is a PDP-11 instruction 
'MOV'. The details of the move instruction mnemonic, MOV, may be 
found in the "Processor Handbook"{4}. In fact, that is the place 
to find the definitive description of all the PDP-11 instructions. 
The MOVe instruction takes two arguments: Source and Destination. 
At BLUE we have 'MOVe the contents of RED into Register Zero'. It 
is a copy operation, the original contents of RED are intact. 
Sixteen bits are MOVed - most of the PDP-11 operations can be 
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conceived as 16 bit parallel operations. A register is storage 
place in the CPU, as opposed to a storage space in main memory{5}. 
There are eight "general purpose" registers on every PDP-11, 
usually called RO, Rl, R2, R3, R4, R5, SP and PC. Guessing from 
the names, registers six and seven are special and not general 
purpose at all - correct. Generally a register and a memory 
location may be used interchangably. Access to a register is 
faster than memory. And, there are some instructions that require 
the use of a register. 

The next line contains the invocation of the macro '.TTYOU'. The 
Language Reference Manual {7} explains that you may use any of the 
alphabetic characters, the ten numeric characters and dot and 
dollar sign to form symbol names. It recommends that you not use 
dot and dollar. Digital has bound itself to the convention that 
ALL the symbols that they use (that might be accessible to you) 
will contain a dot or a dollar sign. This convention makes is 
easier for you to avoid "reserved words". In this case I have 
suggested that you create a macro, .TTYOU, in a file MACROS.MAC, 
that breaks this convention. Here the .TTYOU tells the assembler 
to replace the .TTYOU with whatever has been defined as .TTYOU. 
Since you have created the macro .TTYOU with the incantation 
necessary to output a character for your operating system, the 
assembler will do the sleight of hand for you and we can all talk 
about a .TTYOU without being concerned about the lower level 
rubric. .TTYOU is a "system directive", it requests the operating 
system to move the contents of register zero (RO) out to the 
terminal. Usually there is an ASCII {6} character there, which the 
terminal interprets and prints. Thus the octal 101 is interpreted 
as an upper case A. The octal value 15 is translated by the 
terminal as "carriage return", etc. 

The next exercises are: (l)Modify program ONE to print a Z instead 
of an A. (2)Modify program ONE to print an A followed immediately 
by a Z. (3)Modify ONE to print an A directly over a Z, that is, A 
on one line, and Z at the left margin on the next line. 

It is true that one ASCII character is contained by eight bits, and 
that there are 16 bits in a PDP-11 word. When you put both the A 
and the Z in one word and ask the operating system to print it on 
the terminal, the operating system only prints the one character in 
the "low byte" of "right hand byte" of the word in Register 0. 
Thus, it is necessary to have one MOVe instruction and one .TTYOU 
system directive for each character that is to go to the terminal, 
printing and control. Examine program TWO for example. 

The '.EXIT' is a system directive that informs the operating system 
that the program is done, return the computer to the operating 
system. There may be several .EXIT'S in a program, indicating 
several points in the logic where the program can finish. Only one 
.EXIT is ever executed for one RUN of the program. 

The '.END' is an assembler directive indicating the end of the 
program. The difference here, is that .END is a message to the 
assembler saying "This is the end of my program, ignore anything 


else in this file." or "Stop assembly here." .EXIT is a message to 
the opertaing system, .END is a message to the assembler. There 
must be only one .END in your program. (Occasionally, the file 
MACROS.MAC for example, where there will be no .END.) When the file 
you are creating is the Main program, rather than a subroutine, the 
.END takes an argument - the address of the start of the program, 
the transfer address. In program ONE the computer wil start 
executing the program at the address BLUE. 

Unlike most high level languages, MACRO-11 permits you to mix data 
and instructions. The assembler would not protest if we were to 
place RED after BLUE. The computer might protest when we tried to 
RUN the program, because the data in RED might not make any sense 
when interpreted as an instruction. Thus, at the beginning I 
recommend that you organize your program to place the data at the 
front of your program file, before the start of the program. Or, 
at the end after the .EXIT. 

What to do next? There are several textbooks {8} that will lead 
you through or you may just wrestle with the Language Reference 
Manual and a self imposed project. Or you may find a college 
nearby that offers a course in MACRO-11 at night. Such a course is 
probably more productive than the one week intensive courses 
offered by Digital's Educational Services; learning a language 
takes most people longer than a week. 

The attached subroutine, RDUMP {9}, is included to be used as a 
tool in debugging your early programming efforts. Digital's Octal 
Debugging Tool (ODT) is available with most operating systems, but 
is confusing to learn at the same time you are struggling with the 
assembler. Use RDUMP until you are comfortable with the jargon of 
assembly language; then take on ODT. A sample program using RDUMP: 



.TITLE 

THREE 


.GLOBL 

RDUMP 

Nl: 

.WORD 

1 

N2: 

.WORD 

2 

N3: 

.WORD 

3 

N4 : 

.WORD 

4 

N5: 

.WORD 

5 

GREEN: 

CLR 

RO 


MOV 

Nl, Rl 


MOV 

N2,R2 


MOV 

N3,R3 


MOV 

N4,R4 


MOV 

N5,R5 


CALL 

.EXIT 

RDUMP 


.END 

GREEN 


The .GLOBL assembler directive indicates that the argument, RDUMP, 
is a symbol that is defined somewhere else, and the linker will 
connect any references to RDUMP correctly. RDUMP will print the 
contents of all the registers and the status of the condition codes 
that are found in the Processor Status Word. This subroutine may 
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be executed by a non-priviledged user on a time sharing system, 
without direct access to the PSW. There should be no change to 
your program by the introduction of RDUMP, it saves all the 
registers and condition codes and restores them before returning to 
your program. So, while the example, THREE, uses RDUMP at the end 
of the program, that is not necessary. 

Good luck and perseverance in your pursuit of fluency in MACRO-11. 
Your effort will be rewarded by greater understanding of your high 
level language and a power to perform impossible tasks in a high 
level language by using assembly language subroutines to do the 
'impossible.' 


* Notes * 


{1} For a RSTS/E system, use the RT-11 emulator. Make a file 
MACROS.MAC that contains: 

.MACRO .TTYOU 
EMT 341 

BCS .-2 

. ENDM 

.MACRO .EXIT 
EMT 350 

.ENDM 

For an RT-11 system make the same file MACROS.MAC as above. It is 
arguable that one should us6 the system library, but, for now, do 
it this way. 

For an IAS system or a VMS system, using the PDP-11 emulator. I 
think that this will work on RSX-llM and RSX-llD too. Create a 
file MACROS.MAC that contains: 


.MACRO 
.MCALL 
MOV 
BR 

. BLKW 

QIOW$S 

.ENDM 


.TTYOU, ?A,?B 
QIOW$S 
R0 , A 
B 
1 

#IO.WLB,#5,#1,,,,<#A,#1,#0> 


.MACRO .EXIT 
.MCALL EXIT$S 
EXIT$S 
.ENDM 

{2} The assembly process is very similar to a compiled high level 
language, but quite different from using an interpreted language: 


For RSTS/E: 
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MACRO ONE-MACROS,ONE 
LINK ONE-ONE 
RUN ONE 

For IAS or RT-11: 

MACRO/OBJECT:ONE MACROS+ONE 
LINK ONE 
RUN ONE 

For VMS: 

MACRO/RSX/OBJECT-ONE MACROS+ONE 
LINK/RSX ONE 
RUN ONE 

On some of the above systems there are other possible command 
sequences and abbreviations. These work on the systems that I have 
access to. 

{3} I am presuming, of course, that you understand the basics of 
using your operating system and the use of a text editor. The 
editor that I use is TECO and I recommend it. It is consistent 
across most of the PDP-11 operating systems. 

{4} There have been numerous PDP-11 Processor Handbooks. Any of 
them is sufficient for the beginning MACRO programmer. If you have 
older ones, save them - they sometimes contain details that have 
been removed from the newer ones. A sampling from my bookshelf: 
"PDP11/04/05/10/35/40/45 Processor Handbook" EB-05138-75 (1975) 
"PDPll/70 Processor Handbook" EB-05962-20 (1976) 
"PDPll/04/34a/44/60/70 Processor Handbook" EB-17716-18 (1979) 
"PDPll/04/24/34a/44/70 Processor Handbook" EB-19402-20 (1981) 

The most recent edition seems to follow the example of VAX, the 
volume is now called: 

"PDP-11 Architecture Handbook" EB-23657-18 (1983) 

These books detail the instructions of which the PDP-11 is capable. 

In some cases there are also hints on assembler syntax for some of 

the instructions that was left out of the Assembly Language 
Reference Manual. Whichever edition you have, it is a valuable 
reference to the MACRO programmer. Note, for example, the fine 
print under the MOVe Byte instruction. 

{5} "Main Memory" is what used to be called "core memory." The 
stuff made of little ferrite donuts called cores, not the core of 
an Apple (pardon the expression). Today, main memory is usually 

made of etched silicon chips, as are the registers "within" the 
CPU. The principle difference, then, is where the memory cells are 
in the computer's organizational chart. Registers are close to the 
center of power and have a simple addressing mechanism - making 
access to them quicker. The main memory is usually in another 
physical section of the computer, on another board, in another 

cabinet and the addressing of a single cell more time consuming. 
The actual timing considerations will vary with the model of the 
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PDP-11 and 

considerations. 

the 

presence 

of 

cache memory and other 

such 

{6} American 

Standard Code 

For 

Information Interchange. 

An 


arbitrary code to represent printing and control characters in 
numbers which can be stored in a computer. There are other codes, 
but this is the one most widely used in the PDP-11. The full 
scheme is on the back of the PDP-11 Programming Card. The ones 
used here: 101-A, 12»<line feed>, 15-<carriage return>. 

{7} "PDP-11 MACRO-11 Language Reference Manual" AA-V027A-TC (1983) 
is the most recent in a long line of such manuals. While the most 
recent is nice, the older versions will get you started as well as 
they have most of the MACRO programmers doing it today. Another 
example: "IAS/RSX-11 MACRO-11 Reference Manual" DEC-11-0IMRA-B-D 

(1976). The language has evolved and the older manuals do not 
mention the newer features, but the essential parts of the language 
were well designed and have been left intact. 

{8} These are textbooks discussing the PDP-11 and MACRO-11: Thomas 
S. Frank; "Introduction to the PDP-11 and its Assembly Language"' 
Prentice-Hall, Inc. Englewood Cliffs, NJ; 1983. Charles A. Kapps 
and Robert L. Stafford; "Assemble Language for the PDP-11", 

Prindle, Webber & Schmidt, Boston; 1981. Michael Singer, "PDP-11 
Assembler Language Programming and Machine Organization", John 
Wiley & Sons, New York; 1980. Arthur Gill, "Machine and Assembly 
Language Programming of the PDP-11", Second Edition, Prentice-Hall, 
Inc., New Jersey; 1983. Harry R. Lewis, "An Introduction to 
Computer Programming and Data Structures using MACRO-11", Reston 
Publishing Company, Reston, Virginia; 1981. Systems 
Organization, Programming, and Applications (PDP-11)", Second 
Edition, Prentice-Hall, Inc., New Jersey; 1979. Harrold S. Stone 

and Daniel P. Siewiorek, "Introduction to Computer Organization 

and Data Structures: PDP-11 Edition", McGraw-Hill Book Company, 
New York; 1975. R.W. Southern, "PDP-11 programming Fundamentals", 
Southcroft Publications, Ottawa, Ontario; 1972. Harvey Lee 
Shapiro, "Introduction to Assembly Language Programming on the 
PDP-10 and PDP-11", Myfield Publishing Company, Palo Alto, 
California; 1982. 

{9} The following is a listing of the file RDUMP.MAC. You must 
edit this file to select the correct operating system. About two 
thirds the way down the first page is the statement 
SYSTEM-XXX 

Edit the XXX into the appropriate symbol for your operating system: 
RTll, RSTS, IAS, VMS. Then it should be used with your program as 
follows: 

For RSTS/E: 


For IAS and RT-11: 


MACRO/OBJECT:THREE MACROS+THREE 
MACRO RDUMP 
LINK THREE,RDUMP 
RUN THREE 


For VMS: 


MACRO/RSX/OBJECT-THREE MACROS+THREE 
MACRO/RSX RDUMP 
LINK/RSX THREE,RDUMP 
RUN THREE 


MACRO THREE-MACROS,THREE 
MACRO RDUMP-RDUMP 
LINK THREE-THREE,RDUMP 
RUN THREE 
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File: RDUMP.MAC 
Assembler: MACRO-11 
Programmer: Robert F. Curley 


******************************************************* 
* * 

* DIRECT INQUIRIES TO: * 

* Computer Facility * 

* Department of Radiation Therapy * 

* School of Medicine * 

* University of Pennsylvania * 

* Room 410 * 

* 133 South 36th Street * 

* Philadelphia, Pennsylvania 19104 * 

* * 

* NO WARRANTY OR REPRESENTATION, EXPRESS OR * 

* IMPLIED, IS MADE WITH RESPECT TO THE * 

* CORRECTNESS, COMPLETENESS, OR USEFULNESS * 

* OF THIS SOFTWARE, NOR THAT USE OF THIS * 

* SOFTWARE MIGHT NOT INFRINGE PRIVATELY * 

* OWNED RIGHTS. * 

* * 

* NO LIABILITY IS ASSUMED WITH RESPECT TO * 

* THE USE OF, OR FOR DAMAGES RESULTING FROM * 

* THE USE OF THIS SOFTWARE * 

* * 
******************************************************* 

(Most Recent Edit) 10 January 1984 


Subroutine RDUMP - print the contents of the registers on 
the terminal 

CALL RDUMP 

prints the contents of the registers (in octal) at the time 
of the CALL. It does not alter the registers nor the 
condition codes. 

Output Format: 

Register Dump 

R0«nnnnnn Rl»nnnnnn R2-nnnnnn R3-nnnnnn 
R4-nnnnnn R5=nnnnnn SP-nnnnnn PC-nnnnnn 
Condition Codes 


N-n 

Z-n V-n 

C- 

n 

l l i r r r r i r i i i i i 

.TITLE 

i t t t t r t t i t t i t t t 

RDUMP 



.IDENT 

/!/ 

version 

number 

.DSABL 

GBL 

this is 
works. 

the way MACRO-11 on RSTS 
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RT11-1 

RSTS-2 


*** Define The Operating System *** 

RT-11 or RT-11 emulator under RSTS/E 
with the RT-11 system macro library 
added to the RSTS/E system library. 

RSTS/E under the emulator mode. 


IAS-3 


IAS operating system. 


VMS-4 

SYSTEM-XXX 


RSX emulation on VAX 
Select One 


.IF NDF,SYSTEM ; 

.ERROR; ** You must define the symbol SYSTEM in the 
.ERROR; ** statement above, SYSTEM-XXX, by changing the 
.ERROR; ** XXX to RTll or RSTS or IAS or VMS so that 
.ERROR; ** the appropriate macro for .TTYOU is defined. 
.ERROR; ** 

.ERROR; ** Use a text editor to change this file and 
.ERROR; ** and re-assemble it. 

.ERROR; ** 

.ENDC ; 



.IF EQ, 

< SYSTEM-VMS> ; 


.MACRO 

.TTYOU,?A,?B ; 


.MCALL 

QIOW$S 


. GLOBL 

IO.WLB 


MOV 

R0, a 


BR 

B 

A: 

.WORD 

o 

B: 

QIOW$S 

#10.WLB,# 5,#1,,,,<#A,#1,#0> 


. ENDM 

? 


.ENDC 

} 


.IF EQ, 

<SYSTEM-IAS> ; 


.MACRO 

.TTYOU 7STAT,?BUFF,?SKIP,?Q 


.MCALL 

QIOW$,DIR$ ; IAS code 


MOV 

RO,BUFF ; 


DIR$ 

#Q 


BR 

SKIP ; 

Q: 

QIOW$ 

<10.WLB!IO.WAL>,5,2,,S TAT,,<BUFF,1,000> 

STAT: 

. BLKW 

2 ; 

BUFF: 

. BLKW 

1 

SKIP: 


/ 


.ENDM 

} 


.ENDC 

i 


.IF EQ, 

, < SYSTEM—RTl1> ; 


.MCALL 

.TTYOU ; RT-11 code, use the library 


.ENDC 

i 


•IF EQ, 

, <SYSTEM-RSTS> ; 
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.MACRO .TTYOU 
EMT "0341 

BCS .-2 

. ENDM 
. ENDC 


RSTS/E code 


.MACRO PUSH,REGLIS 
.IF NB,<REGLIS> 

.IRPC REG,<REGLIS> 
MOV %REG,-(SP) 

.ENDM 
.IFF 

.IRPC REG,<012345> 

MOV %REG,—(SP) 

.ENDM 

.ENDC 

.ENDM 


<<< PUSH >>> 

Invocation: PUSH <012> or PUSH 

Push the indicated registers onto 
the stack. If no register list 
is used a PUSH <012345> is 
assumed. 


.MACRO POP,REGLIS 
.IF NB,<REGLIS> 

.IRPC REG,<REGLIS> 
MOV (SP)+,%REG 

.ENDM 
. IFF 

.IRPC REG, <543210 

MOV (SP)+,%REG 

.ENDM 

.ENDC 

.ENDM 


<<< POP >>> 

Invocation: POP <210> or POP 
The order should be reversed from 
the PUSH specification if specific 
registers are named. 

A POP without argument is assumed 
to be POP <543210> 


.MACRO SAVE,Z,N,V,C 

CLEAR-0 

SET-0 

.IF EQ, N 
CLEAR-"BIO00 
.IFF 

SET-"B1000 

.ENDC 
.IF EQ, Z 

CLEAR-CLEAR l "BlOO 

.IFF 

SET-SET » "BlOO 
.ENDC 
.IF EQ, V 

CLEAR-CLEAR I "BlO 

.IFF 

SET-SET ! "BlO 
.ENDC 
.IF EQ, C 
CLEAR-CLEAR I 1 
.IFF 

SET-SET ! 1 

.ENDC 


<<< SAVE >>> 

Create bit masks of the condition 
codes. The bit mask for the bits 
to be set is stored in SSAVE. 

The mask for bits to be cleared 
is stored in CSAVE. 
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MOV 

#SET,SSAVE 



MOV 

#CLEAR,CSAVE 



JMP 

RED 



.ENDM 






<<< Entry Point >>> 

RDUMP: 

BNE 

10$ 

Save the Condition Codes 

Z branch if Z-0 


BPL 

12$ 

N branch if N-0 


BVC 

14$ 

V branch if V-0 


BCC 

16$ 

C branch if C-0 


SAVE 

1,1,1,1 

Zl,Nl,Vl,Cl 

16$: 

SAVE 

1,1,1,0 

Zl,N1,V1,C0 

14$: 

BCC 

20$ 

C branch if C-0 


SAVE 

1,1,0,1 

Zl,Nl,V0,Cl 

20$: 

SAVE 

1,1,0,0 

Zl,N1,V0,CO 

12$: 

BVC 

22$ 

V branch if V-0 


BCC 

24$ 

C branch if C-0 


SAVE 

1,0,1,1 

Zl,NO,Vl,Cl 

24$: 

SAVE 

1,0,1,0 

Zl,NO,VI,CO 

22$: 

BCC 

26$ 

C branch if C-0 


SAVE 

1,0,0,1 

Zl,NO,V0,Cl 

26$: 

SAVE 

1,0,0,0 

Zl,NO,V0,CO 

10$: 

BPL 

30$ 

N branch if N-0 


BVC 

32$ 

V branch if V-0 


BCC 

34$ 

C branch if C-0 


SAVE 

0,1,1,1 

Z0,Nl,Vl,Cl 

34$: 

SAVE 

0,1,1,0 

Z0,N1,V1,C0 

32$: 

BCC 

40$ 

C branch if C-0 


SAVE 

0,1,0,1 

Z0,N1,V0,C1 

40$: 

SAVE 

0,1,0,0 

Z0,N1,V0,C0 

30$: 

BVC 

42$ 

V branch if V-0 


BCC 

44$ 

C branch if C-0 


SAVE 

0,0,1,1 

Z0,N0,V1,C1 

44$: 

SAVE 

0,0,1,0 

Z0,N0,V1,C0 

42$: 

BCC 

46$ 

C branch if C-0 


SAVE 

0,0,0,1 

Z0,NO,V0,Cl 

46$: 

SAVE 

0,0,0,0 

Z0,NO,V0,CO 

RED: 

PUSH 

<0123> 

Save Registers 

The Stack now looks like: 




PC (from JSR instruction) 

— R0 

— Rl 

— R2 




SP>— R3 


MOV 

#STRl,Rl 



JSR 

R2,PRINT 



JSR 

R2,RNAME 



.WORD 

"R0 



MOV 

6(SP),Rl 

Register Zero 


JSR 

R2,OCTAL 
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JSR 

R2,RNAME 

.WORD 

"Rl 

MOV 

4(SP),Rl 

JSR 

R2,OCTAL 

JSR 

R2,RNAME 

.WORD 

"R2 

MOV 

2(SP),Rl 

JSR 

R2,OCTAL 

JSR 

R2,RNAME 

.WORD 

"R3 

MOV 

(SP),R1 

JSR 

R2,OCTAL 

CALL 

CRLF 

JSR 

R2,RNAME 

.WORD 

"R4 

MOV 

R4, Rl 

JSR 

R2,OCTAL 

JSR 

R2,RNAME 

.WORD 

"R5 

MOV 

R5, Rl 

JSR 

R2,OCTAL 

JSR 

R2,RNAME 

.WORD 

"SP 

MOV 

SP, Rl 

ADD 

#12,Rl 

JSR 

R2,OCTAL 

JSR 

R2,RNAME 

.WORD 

"PC 

MOV 

10(SP),R1 

JSR 

R2,OCTAL 


MOV 

#STR2,Rl 

JSR 

R2,PRINT 

JSR 

R2,RNAME 

.WORD 

" N 

BIT 

# A B1000,SSAVE 

CALL 

BIT 

JSR 

R2,RNAME 

.WORD 

" Z 

BIT 

# ~B100,SSAVE 

CALL 

BIT 

JSR 

R2,RNAME 

.WORD 

" V 

BIT 

#~B10,SSAVE 

CALL 

BIT 

JSR 

R2,RNAME 

.WORD 

" C 

BIT 

#1,SSAVE 


Register One 


Register Two 


Register Three 


Register Four 


Register Five 


Stack Pointer 
calculate original value 


Program Counter 

print address of the next inst. 
in the calling program 


N bit 


Z bit 


V bit 


C bit 
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CALL 


BIT 


CALL CRLF 


MOV #000240,CRI1 

MOV #000260,CRI2 

BIS CSAVE,CRIl 

BIS SSAVE,CRI2 


POP <3210> 

CRIl: . BLKW 1 

CRI2: .BLKW 1 

RETURN 


Create instructions to restore 
condition codes to the pre-RDUMP 
values. 

The instruction in CRIl will 
Clear the required condition 
codes while the instruction in 
CRI2 will set any that should 
be set. If none need to 
be set, each is left a NOP. 

Note: 260 is an undocumented NOP. 
Restore Everything 

Created Instructions 
to restore condition codes 
EXIT 


<<< Data >>> 


STRl: .ASCIZ <15><12>/Register Dump/<15><12> 

STR2: .ASCIZ <15><12>/Condition Codes/<15><12> 

SPACES: .BYTE 40,40,40,40,40,40,0 
.EVEN ; 

SSAVE: .BLKW 1 ; 

CSAVE: .BLKW 1 ; 


RNAME: 


MOV #40,R0 

.TTYOU 
.TTYOU 

MOVB (R2)+,R0 

.TTYOU 

MOVB (R2)+,R0 

.TTYOU 

MOV #'-,R0 

.TTYOU 
RTS R2 


<<< RNAME >>> 

Print the sequence: Space, Space 
2 character register name, equal 
sign. 

40-space 


get 1st argument character 

2nd, now R2 points to return address 


CRLF: 


MOV 
.TTYOU 
MOV 
.TTYOU 
RETURN 


#15,R0 

#12,R0 


<<< CRLF >>> 

print carriage return and line feed 


BIT: BNE 10$ 

MOV #'0,R0 


<<< BIT >>> 

print a 1 or 0 for the condition 
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10$: 

20$: 

BR 

MOV 

.TTYOU 

MOV 

JSR 

RETURN 

20$ 

#'1,R0 

#SPACES,Rl 

R2,PRINT 

code status. 

OCTAL: 

PUSH 

<02> 

<<< OCTAL >>> 


CLR 

R0 



MOV 

#6, R2 

Invocation: JSR R2,OCTAL 


BR 

20$ 

with the value to be printed in 

10$: 

CLR 

R0 

octal in Rl. 


ROL 

Rl 



ROL 

R0 



ROL 

Rl 



ROL 

R0 


20$: 

ROL 

Rl 



ROL 

R0 



ADD 

#60,R0 



.TTYOU 




DEC 

R2 



BNE 

10$ 



POP 

<20> 



RTS 

R2 


PRINT: 

PUSH 

<0> 

<<< PRINT >>> 

10$: 

MOVB 

(Rl)+,R0 



BEQ 

DONE 

Invocation: JSR R2,PRINT 


.TTYOU 


with the address of the string to 


BR 

10$ 

PRINTed in Rl. The string must be 

DONE: 

POP 

<0> 

be terminated by a zero byte. 


RTS 

R2 



.END 
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CHAIRPERSON’S ARTICLE 

Here we go again. Time for the Spring Symposium in Dallas. All of you 
should have received information on the symposium including registration, 
hotel, and schedule details. Dallas should present an opportunity for 
attending some interesting activities. The SIG is sponsoring sessions to 
begin to acquaint new highend VAX sites with some of the information needed 
to make their systems really work. These sessions should be of significant 
value to Large Systems SIG members who have chosen to follow an integrated 
path that includes VAX systems as well as to new highend VAX sites. Both 
managerial and technical issues will be presented. A significant number of 
sites have now ordered and/or installed highend VAX systems and clusters to 
supplement or replace 36 bit systems. A track of sessions has been 
scheduled to meet the needs of highend system installations. We are 
attempting to meet the needs of this growing community that has many common 
concerns, and will be supporting additional activities, products, and services 
even more so in the future. 

The Dallas symposium will certainly include those session that we normally 
present to serve the needs of the installed base of 36 bit systems. In 
particular, sessions will be held to identify the precise details of what 
we want to see as development efforts from DEC in our final years of the 
promised five years of active development. We are nearly three years into 
the five year period, and can assume that time is rapidly disappearing for 
inclusion of new features/functiona1ity. These sessions in Dallas are 
intended to be perhaps the final opportunity for voicing desires and 
concerns for development oriented efforts. Please give this area 
considerable thought in preparation for attending these sessions. Other 
issues, particularly dealing with long term support, will be emphasized 
also. 

The Large Systems SIG is sponsoring a special attraction that no one will 
want to miss. As requested, a new version of our extremely popular 
VAXBUSTER shirts will be available for purchase in the DECUS store. The 

1985 version was so popular at the Anaheim symposium that the entire stock 
of shirts sold out - most on the first day. We're sure you'll love the 1986 
model. So be sure you get yours before they sell out. 

1986 marks a milestone in the life of DECUS. It is the 25th anniversary of 
the society. To mark the occasion, DECUS is sponsoring a number of 
special events, some of which are similar to those presented when we 
celebrated our 20th anniversary in 1984. There will be exhibits of 
memorabelia, special sessions, and a gala Texas-style of celebration. If 
you'd like to participate or if you've got a DECUS artifact that you're 
willing to loan to us for the exhibit, please contect me or just bring it 
to the symposium. 

Nothing in Texas is small, and we expect the symposium to be a big success. 

The Large Sytems SIG will live up to the expectations of presenting a big 
Texas-style of symposium. See you there soon. 
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PANDA PROGRAMMING 

1802 Hackett Ave., Rainbow Suite 
Mountain View, CA 94043-4431 
USA 

+ 1 (415) 968-1052 
Mark R. Crispin, President 
Friday, 3 January 1986 

Open Letter to the 36-Bit Community 
c/o Leslie Maltz 
Computer Center 
Stevens Institute of Technology 
Hoboken, NJ 07030 

Dear Leslie. 

I was disturbed by the results of the Spring 85 Large Systems Menu. I interpret what happened 
In two ways. First, the ■everybody can vote" as opposed to "per site" voting policy was not made 
clear. Second, sites which have picked non-VAX alternatives may no longer care about what DEC 
does, and abstained from voting. The result is clear; the results represent primarily those sites which 
are staying with DEC and hence are migrating to VAX/VMS. 

I wish to remind everyone that there Is less than 2 1/2 years left In DEC'S promised 5-year 
period of 38-bit development. We should do our best to Induce DEC to use this time to our maximum 
advantage. I have several suggestions to allow us all to use our menu most effectively: 

First, those of us who are migrating to VAX/VMS should bring VAX-related issues in the VAX 
Systems SIG Menu and not the Large Systems SIG Menu. That way, our needs would be known by 
the entire VAX/VMS community. The 36-bit community knows quite well what VMS’ limitations are 
for large sites; it isn't clear that the VMS community dees. Remember that most of the latter sites 
came from the PDP-11 world and see VMS as a completely fantastic reimplementatlon of RSX. Our 
presence in their forum Is the best way to educate them. 

Second, we should give serious consideration to what DEC can (and is willing to) do in 2 years. 
I'm sure all TOPS-20 sites would like a native mode MACRO and LINK. I’m sure all TOPS-10 sites 
would like extended addressing languages. All of us would like to see the KL trade-in offer continue 
forever. These things have about as much chance of happening as DEC'S deciding to "uncancel" the 
36-l>it product line. It is a waste of votes to ask DEC for things they will say ■no" to. 

Third, we should not waste votes on solved problems. Several of the menu items referred to 
changes DEC has already made, or to software enhancements already done by customers and freely 
distributed (more on this below). DEC should be adopting desirable changes from customers without 
being asked. Even if DEC doesn't, we should have DEC working on projects that are best (or can only 
be) done by DEC. This leads me to... 

Fourth, we should concentrate our votes on language development. It's a waste of the little 
time we have left to have DEC continue to play with the operating systems. We might as well have 
DEC rreeze them now and concentrate on correcting the dismal state of TOPS languages. I suggest a 
single menu item, to avoid the current fragmentation of our concerns In this area — "Finish languages: 
support up to latest ANSI standards (at least up to current I'LY/VA/S support level). Extended 
addressing support in all languages; at least 1 section code+rnulti section data on TOPS-CO, and 
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preferably multi-section code/data on both TOPS-SO and TOPS-IO.” [Why not? Maybe there'll be 
enough time left for the brillant TOPS-IO hackers to do extended languages after all...) 

Fifth, help yourselves in your on-site support and help the outside vendors who plan on offering 
development and support of 36-bit hardware and software in the post-DEC era. Menu Items 1.5 and 
1.7 are particularly Important -- TOPS license fees for third-party CPU’s should be reduced now. 
When development end. TOPS and all associated software (utilities, languages, etc.) should be placed 
In the public domain and sources provided to all customers. 

To elaborate on this last point, there are organizations which are willing and eager to take over 
TOPS operating system and utility development for as long as there are sites that are willing to pay 
for It. DECUS commercialism guidelines keep me from naming any names, but at least one hardware 
vendor Is building fast (and physically small) 36-blt CPUs that run TOPS. At least one software 
vendor has Incorporated the public-domain "solved problems" mentioned above (along with many 
other Improvements) Into an enhanced TOPS-20 (distributed as REDIT updates). There Is no longer a 
need to wait on DEC to improve the operating systems. Once DEC releases Its proprietary rights to 
TOPS these vendors will be free to develop and distribute these enhanced versions as complete 
packages to the entire community. 

As a final plug, please remember language development. I am afraid that once DEC throws In 
the towel language development will end for good. If It doesn’t get done now it may never get done! 

Warmest regards for the New Year, and keep the faith. 


Sincerely, 



DOCTOR TOPS 


Dear Doctor Tops, 

I have a vintage KI-10 console that 
and make operational. I have taped 
of the switches, giving me 32 bits. 


I want to hook up to my VAX, 
over four of the lights, and four 
What do I do next? 


Bare Metal 


Debugger 


Dear BDM, 

You are off to a good start! What you need to do next is as follows 

1) Renumber the lights, from left to right starting at "31" and ending 
at "0", to be like powers of two. This gives you the correct bit 
numbers. Do the same for the switches. 

2) Turn the voltage margin knob to one extremety or the other, since 
the power supplies of the 11/780 are non-ajustab1e anyway. 

3) Turn the speed control "coarse" knob to "1" for SLOWEST operation. 
Turn the speed control "fine" knob CCW to stop as per above. 

4) Tape over all the "Pi" lights, since the priorities on the VAX 
are all software anyway. 

5) Relabel the "USER CONCEAL" light to be "EXEC". 

Relabel the EXEC MODE and USER MODE labels to "PROCESSOR MODE". 

6) You might want to use the "PI" lights to complete the 
PROGRAM COUNTER display which needs 32 bits. 
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Dear Doctor Tops, 

I have a largish FORTRAN program that I am running on my 2060 that 
I want to move to my 780. The program uses 6 sections for data, and 2 for 
code. It takes about 3:15:00 for a short run and 5:30:00 for a long run in 
CPU time. The elapsed time is very close to CPU time. When I run this 
program on the VAX, it takes 4:30:00 for the short run in CPU and 10+ hours 
of real time. The VAX is otherwise IDLE when this program runs. What can I 
do to help this program run in less real time on the 780? 

Big Simulator 


Dear Big Sim, 

In investigating your program, I see you are doing several things 
that VMS does not handle as well as TOPS20. The first is page faulting, 
the second is DIRECT i/o. Most of your array references are to new pages 
because of the size of your arrays and the order you index them in. To 
correct this would take a much greater effort in re-programming than is 
really desirable. A simpler step would be to increase your WORKING-SET 
size to at least 2048 pages, and 4096 pages would be better (the program 
alone takes up 8,000 pages without the RTL images). This should cut down 
on the page faulting and reduce your real time to runtime ratio. If you 
don't have 8MB on your VAX, you should get it or more. The AUTHORIZE 
utility can change your WSQUO. 

The second problem is in the amount of ACCESS=DIRECT i/o you are 
doing. RMS has to do a lot of running around for every i/o request it 
gets. In running a test case of your program I noted some 900,000 of 
these. You only had 400,000 page faults. Either you re-write your code 
and remove these (sequential) direct i/o calls, or you can change your RMS 
parameters with SYSGEN. Since the VAX has a lot more address space than the 
20, you might consider reading in the WHOLE database you are working with. 
This will eliminate all those i/o calls. 

The real time change going from a 20 to a 780 is suprising. A real 
VMS guru could make the program run better by additional tweaking, but only 
at the expense of making some other application run worse. 

Dr. Tops 

PS: I will gladly answer most any TOPS to VMS conversion questions or any 
related topics. Send your questions or comments to Dr. TOPS in care of 
the Large Systems SIG newsletter editor: 

Michael D. Joy 

The First Church of Christ, Scientist 

Christian Science Center A31 

Boston, MA 02115 
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The Networks Special Interest Group (SIG) is one of 25 SIG's within in 
Digital Equipment Computer User’s Society (DECUS). The main purpose of 
the Networks SIG is to promulgate information concerning the use, 
development, and standardization of network products that function or 
involve Digital Equipment Corporation systems. Additional functions of 
the SIG include the coordination and scheduling of symposia sessions, 
providing methods for free-flow communications, publication of the 
Networks SIG newsletter NETWords, participation in domestic and 
international standards committees, input to Digital for new products and 
corrections to existing products, promotion of working groups for special 
network needs and topics, and many, many other functions. 

The Networks SIG Steering Committee invites you to participate in the 
Networks SIG. There are many ways that you can help the Networks SIG. 
Some of those include chairing sessions at symposium, participation in the 
various Networks SIG working groups, participation in special research 
projects, and others. If you are interested in devoting your time and 
expertise, contact any of the steering committee members. 

DECUS is run entirely by volunteer leadership. Help us make DECUS and the 
Networks SIG better - take an active part in your SIG! 
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From The Editor 


Our April issue offers some useful information about the 
OA SIG's services during Symposia and throughout the year. 
We also have a feature article by Randy Buck, our new Tape 
Copy Coordinator and a final review of the sessions being 
offered by OA in Dallas. 

Hope to see you all in Dallas. 



275 London 
Wheeling, IL 60090 
(312) 459-1784 
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OA SIG SERVICES 


As we approach another Symposium, we would like to take a 
moment to review the services offered by the Office Auto¬ 
mation Special Interest Group (OA SIG). These services are 
provided during the symposoium and throughout the year to 
serve DECUS members interested in OA. 

* £ver_50_hours_of_OA_se£sions will be offered at the 
Dallas Symposium. Contact Mitch Brown (716) 890-4900 
if you would like to find out more about giving a 
session at the next symposium. 

* Bir ds Of a Feather (BOF) meetings will be scheduled as 
informal sessions during Symposia at your request. 

* Ex£Cu tiv e_Track_Day: for Senior Management. The OA SIG 
and Digital will once again sponsor an Executive Track 
Day during the Dallas Symposium. This is an opportunity 
for executives to share insights and develop new ideas 
for their company's Office Automation. If you would like 
your senior management to participate, please contact 
Kit Trimm (602) 886-5563. 

* One day Pre-Sym po sium Seminars (PSS) are offered on Sunday 
before the start of the symposium. They address specific 
topics in greater detail than a one hour symposia session 
can. The OA SIG is sponsoring the PSS "Why All-In-1 is 
Not Office Automation". For more information on attending 
or giving a PSS, contact Sal Gianni (203) 665-5652. 

* 0A_Ta£e_Swa£: For more information on the Tape Swap see 

Randy Buck's article in this issue. 

* 0A_Loca^_U^ers^_Grou£_(^LUG2• The first OA LUG has been 
formed in the Washington DC area. For more information on 
starting a LUG in your area contact Tom Orlowski, HQ Dept, 
of Army, Alexandria, VA. 

* S ££ t e m_Z.2i2E.2X S. 3H ® H t ® ® s.;t S ^FO • SIR’S are presented to 
Digital twice a year by the A0 SIG. Anyone can submit an 
SIR either in person at the Dallas Symposium "OA Wishlist 
Session" on Friday, May 2nd, or by completing the SIR form 
in the tear-out section of this newsletter. For more in¬ 
formation contact Catherine Ditamore (215) 574-7161. 

* 2 A t £ £ • The 0A newsletter appears each month in this 

publication. It is a forum for you, our readers, to share 
ideas and information with one another. Contact Therese 
LeBlanc (312) 459-1784 with submissions. 
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We invite each of you to introduce yourselves to the 0A 
SIG Members (listed in the front of our newsletter) during 
the Dallas Symposium. We would like to meet you and answer 
any questions you may have regarding these services. If 
you have an idea for a service that is not listed here, 
please tell us about it, new ideas and volunteers are always 
welcome! 


FIRST TIME ATTENDEES 


Is Dallas going to be your first symposium? Confused by all 
the things to see and do? Wondering how you will find your 
way around amid all the 'old pros'? We would like to help 
you ! 

Please make sure you attend the Welcoming Reception on Sunday, 
April 27th, from 9:00 P.m. - 10:00 P.M. in the Chantilly Ball¬ 
room, lobby level, Loews Anatole Hotel. Come to the 0A area 
and introduce yourself as a first timer, we will help answer 
many of your questions and introduce you to other people with 
similar interests. 

Also make sure you attend the First Timers Meeting Sunday at 
6:30 P.M. in the same Hotel. 


OA—2—2 














M ONDAY 


9 

00 - 

9 

30 

0006 

9 

30 - 

10 

30 

0021 

10 

30 - 

11 

30 

0019 

11 

30 - 

12 

30 

0059 

12 

30 - 

1 

30 

0026 

1 

30 - 

2 

30 

0049 

2 

30 - 

4 

00 

0022 

5 

00 - 

6 

00 

0050 

6 

00 - 

7 

00 

0051 

7 

00 - 

8 

00 

0048 

8 

00 - 

9 

00 

0044 

9 

00 - 

10 

00 

0025 
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Keynote: OA — The State of the Art 
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Customizing ALL-IN-1 User Documentation 
PCs in Office Systems 

Programming a Message Router Application 
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VAX Teamdata and VAX Rally: Ofc. Info. Solutions 
Selling OA: ALL-IN-1 Meets Madison Avenue 
ALL-IN-1 System Customization Panel 
OASIG General Meeting 

Computer Conferencing: The Next Step in Business 
Communications 

Human Factors for Office Products 
Videotex for Managers 

Why ALL-IN-1 is Not Office Automation 
User Support Groups for OA Products 


WEDNESDAY 
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CALL FOR TAPE SUBMISSIONS 


I would like to bring everyone up to date (within 30 days or so) 
on the OASIG tape project. First of all there will be a small 
tape available shortly. Secondly, I need your input for the next 
tape. 

- No submission is too small (or too big) If all you have is 
one little file that does something special for an OA user, go 
ahead and send it in. 

- Documentation should not prevent you from submitting 
something All you need to do is create an AAAREADME.TXT file 
with enough information to use your submission. Include your 
name and phone number so I may contact you if I need to add 
something. 

- Contributions do not have to be ALL-IN-1 specific Office 
Automation includes many products. Enhancements for Datatrieve, 
DECALC, DECGRAPH, DECSLIDE, DECSPELL, DECTALK, WPS+, and so on 
are welcome. 

HOW DO I SUBMIT MATERIAL? 

Create a tape of your contributions with VMS BACKUP. Please 
record the tape at 1600 BPI. Even though your contribution may 
only require a few blocks, use a 2400 foot reel. Package your 
tape in a re-usable container or include a large padded envelope 
that the tape can be returned in. 

On the tape: 

Use a directory tree to separate large or multiple submission 

Include an AAAREADME.TXT file in each directory. This text 
file should contain a brief description of your submission, w 
it does, and how to use it. 

Use file and directory names that can be used on VMS 3.x. 

If your submission includes FMS forms, put them in a 
USER.FLB file. 

Please fill out and include the DECUS Program Library Submittal 
Form with your submission. For the small amount of time it takes 
to fill out this form you will be rewarded with a very nice 
plaque acknowledging your contribution to the DECUS library. The 
entire OASIG tape will become available from the DECUS library 
only if everyone fills out the submittal form. 

When you send your submission on tape, I will return to you the 
entire OASIG collection. At this time a 600 ft reel would be 
adequate but I expect the OASIG tape project to grow rapidly 
over the next year or so. Who knows, it may become as large as 
the VAX sig tape! 
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One of the things I can do to aid in the creation of the tape is 
to allow submissions in formats other than mag tape. At this 
time I have access to a RAINBOW PC and an IBM PC which can be 
used for downloading files to the VAX. If you have a short .SCP 
or .COM file (less that 100 lines) I would be willing to type it 
in from hardcopy. 

Send your submissions to: 

Randall Buck 

Columbia Savings and Loan 
17911 Von Karman Avenue 
Irvine, CA, 92714 
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From the Editor 


An Apology 

I would like to take this time to apologize for missing the 
February 1986 issue. The issue was assembled and sent via Express 
Mail on December 27, 1985. Where it went is not known - not even 
by the Post Office. If I receive further information from the Post 
Office, I will pass it on. 


Please send all Multitasker submissions and correspondence 
to: 


Dominic DiNollo 
Loral Electronic Systems 
Engineering Computer Center 
Ridge Hill 

Yonkers, New York 10710 
(914) 968-2500 ext 2210 


How to Contribute to the Multitasker 


The Multitasker publishes articles and notes on all topics dealing 
with or relating to RSX based systems. If you are doing something 
new or innovative with RSX we would like to hear from you. 

Please send all correspondence for publication in machine readable 
form. A list of acceptable media and formats follow. If these 
formats are a problem for someone, please call. Alternate 
arrangements such as electronic transfer may be possible. 


Magnetic Tape: 
Floppy Disk: 

TU58 Cart 


1600/6250 BPI 
8 Inch 

5 Inch 


BRU, PIP, FLX, 
VMS BACKUP 

RX01/RX02 
ODS-1 or ODS-2 

RX50 
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The RSX System Manager 


Following a long respite on the checkpoint file, the System Manager 
column returns to the Multi-Tasker. This column appears 
semi-regularly, and presents short articles dealing with the 
day-to-day management of RSX systems. Suggestions and comments are 
welcome I 


...And Still More on Undeleting Files 


In the May, 1985 issue, I discussed methods for recovering files 
that had been deleted unintentionally [1]. One of the tools I had 
mentioned was written by P.G. Hansell, and had appeared in the 
December, 1980 issue of the Multi-Tasker [2]. Since I did not have 
a copy of that issue, I could not describe Hansell's program. 

James M. Rengel of the University of Kansas Medical Center 
generously sent me a copy of Hansell's article. Additionally, 
James included a copy of a program, SOS, which is available (in 
source listing format only) under program number 11-507 in the 
DECUS Library. 

Hansell's program, UNDELETE, scans a device for a particular 
filename and filetype, and dumps each matching deleted file header 
to a list file. After user verification, UNDELETE modifies the 
deleted file header to make a deleted file appear as though it were 
not deleted. The user may then copy the file by file ID to another 
device, and then delete the "undeleted" file for good. 

SOS is very similar to Kirkraan's UND program [3]. A deleted file 
is copied to another device by interpreting the retrieval pointers 
in the deleted file header and using logical I/O to read the blocks 
of the file. SOS will recover only one file at a time, which may 
be better at times than recovering an entire directory using UND. 

In future columns, methods of recovering from other types of disk 
disasters will be explored. 

********************************************* 


RSX—llM—Plus: The System Disk and Volume Valid Processing 


RSX—11M—Plus users who have inadvertently spun down their system 
disk while the system is running notice a funny thing: the system 
becomes unusable and must be rebooted, even after the system disk 
is spun back up and becomes ready. This will happen whenever the 
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system disk momentarily becomes "not ready" due to vibration, power 
sags, or momentary loss of servo. Other disk drives on the system 
can be dismounted and remounted to recover from this situation; why 
should this be a fatal condition with the system disk? 


1 BACKGROUND: VOLUME VALID ON M-PLUS 

M—Plus uses a "volume valid" processing thread to facilitate disk 
volume integrity. Volume valid processing is performed by all 
M-Plus disk drivers when a function is dequeued from the I/O queue. 
The routine $VOLVD, which is located in Executive module MDSUB, is 
called by a disk driver after dequeueing an I/O packet. When 
invoked, $VOLVD checks the software volume valid bit (US.VV) in the 
Unit Control Block. If the bit is off, then volume integrity 
cannot be assured, and an I/O error code of Device Not Ready 
(IE.DNR) is forced. Typically, software volume valid is set when a 
volume is mounted and is cleared when the volume is dismounted. 

In addition to software volume valid, most disk drives employ a 
"hardware volume valid," which is set when the drive is commanded 
to clear error conditions and the drive control logic determines it 
is operating properly. The hardware volume valid is cleared when 
one of many error conditions, or faults, occurs within the drive. 
One of these conditions occurs when a manual or automatic spin down 
request is honored. The disk drive will subsequently refuse all 
commands, even if the drive has become ready again, until the 
controller manually clears the error condition. 


2 THE PROBLEM, AND ONE SOLUTION 

So, why does the system go down when the system disk goes down? 
First, the hardware volume valid is cleared when the drive control 
logic realizes there is a problem. Subsequent I/O requests are 
rejected by the drive, resulting in IE.DNR completion errors. 
Since the only RSX-llM-Plus software that issues a request to reset 
the hardware volume valid is MOU (and VER, which we will examine 
later), and MOU cannot be loaded from the system disk, the only 
recourse is to reboot the system. 

A simple workaround is to have copies of MOU and DMO installed from 
another disk. Then the system disk could be dismounted and 
remounted in the event of a failure. The workaround becomes less 
simple, however, if other system activities, such as console 
logging, queue management, and checkpointing, are active on the 
system disk. The support tasks for these subsystems would also 
require copies to be installed on another disk. Additionally, a 
privileged user would be required to perform the recovery. 

Applying the Remount Verification Task (VER...) to this situation 
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did not seem feasible. VER... is designed to operate exclusively 
with the RC25 subsystem and the MSCP driver (DUDRV). VER... is 
invoked directly by DUDRV when remount verification is necessary. 
Modifying all other disk drivers to invoke VER... when necessary 
would be a clumsy solution. 

An automated workaround to this problem is simple, in principle. 
Setting software and hardware volume valid can be accomplished by 
using a QIO directive with an IO.STC (Set Characteristics) function 
with the second parameter word set to the logical value W$SET. 
When the driver calls $VOLVD with an IO.STC and W$SET combination 
and a series of tests are passed, $VOLVD will set the software 
volume valid bit and return to the driver. Next, the driver issues 
the appropriate command to the disk drive to reset the hardware 
volume valid. The drive is now receptive to subsequent I/O 
requests. 

We have implemented this automated workaround in a "volume valid 
daemon" that monitors the state of the system disk and resets the 
volume valid bit when the drive momentarilly goes down. The 
program, WC (Volume Valid Control), is activated when the system 
is started. At five second intervals, WC issues an IO.STC QIO 
request with the W$SET parameter to the system disk. The QIO 
causes the drive to be interrogated, with a successful status 
returned if the drive is operational. If the drive happens to be 
down, WC enters a recovery mode of operation. Recovery of volume 
valid is actually a tricky process, due to the checks that the 
$VOLVD routine performs and the desire to keep other system tasks 
and users from accessing the drive until it is made operational. 

In order to keep system tasks (such as COT..., ERRLOG, QMG..., 
etc.) from accessing the system disk after loss of volume valid, 
WC employs the same "trick" used by the Remount Verification Task 
(VER...) when remounting RC25 multi-drive, single spindle units. 
The trick is to set the "Stall I/O" bit, US.SIO, in the UCB of the 
system device. When this happens, the $GTPKT routine will not 
dequeue any I/O requests for the system disk UNLESS the requesting 
task is VER... (The system compares the TCB in the I/O packet with 
the contents of $VERTK, a reserved word in the Executive.) WC 
temporarily replaces the contents of $VERTK with its own TCB 
address. At this point, all I/O to the system disk is "stalled" 
with the exception of I/O requests from WC. 

WC now issues IO.STC QIO requests with the W$SET parameter every 
second until a successful status from the system disk is returned. 
Once the disk has recovered, WC verifies that the volume has not 
changed (i.e., the disk pack is still the same). This is 
accomplished by reading the Home Block on the system disk, 
verifying the checksums in the Home Block, and comparing the volume 
label stored in the Volume Control Block with the volume label in 
the Home Block. If these tests pass, WC clears the stall I/O bit, 
calls the driver to resume processing I/O requests, restores the 
contents of $VERTK, requests VER... (in case any verification work 


is required for another disk), and prints a message on the console 
indicating that volume valid has been reset. 


3 SUMMARY 

This program has been tested and operated continuously on a 
PDP-11/70 running RSX-llM-Plus V2.1E for four months. The system 
disk on this system is a DEC RM03. The program has also been 
tested on an LSI-11/73 with a third party MSCP-compatible 
controller and Winchester disk. WC occupies 768 words of memory 
(including external header), and (of course) is not checkpointable. 
The program is availble on the Fall 1985 RSX SIG tape in UIC 
[ 307,20] . 


4 ACKNOWLEDGEMENTS 

I would like to thank Larry Baker for his advice during the 
development of the Volume Valid Control program, and to thank Larry 
and Tim MacDonald for reviewing this paper. I would also like to 
thank those users who, while mounting their magtapes, have bumped 
into the RM03 "START" button, bringing the disk and the system 
down. This software was developed at the National Strong Motion 
Data Center, located at U.S.G.S. in Menlo Park, California. 


References: 


[ 1 ] 


Maxwell, Gary, "The System Manager: Recovering From Disk 

Disasters, Part I," Multi-Tasker, May, 1985, pp. 4-10. 


[2] Hansell, P. G., 
Multi-Tasker, Vol. 


"UNDELETE Program for RSX 
14, No. 1, December 1980. 


Disks," 


[3] Kirkman, Richard, "UND, a Program to Undelete Files," 

Multi-Tasker, Vol. 15, No. 1, July 1981, pp. 12-18. 

Program source availabilty: Spring 1983 RSX SIG tape, UIC 
[370,210]. 


********************************************* 


Please send questions, comments, ideas and submissions for this 
column to the following address: 

Gary Maxwell 
U.S.G.S. M/S 977 
345 Middlefield Road 
Menlo Park, CA 94025 
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Modifying PRT's Print Buffer 


Paul Matteoni 
Northern Micrographics 
3110 International Lane 
Madison, WI 53704 


PRT wiil truncate lines too large to fit in tis buffer. This can 
happen when PRT tries to print RUNOFF output of underlined text. 

This patch describes how to enlarge the print buffer for the single 
queue print spooler (PRT). 

1. Set your UIC to [1,24] and create the file IOPRT.PAT: 

.TITLE IOPRT 

.IDENT /07.01A/ 

.MCALL FDBDF$, FDOP$A, FDRC$A 

GETLUN—4 


.PSECT INPPT,D,GBL 

$INPPT:: 

FDBDF$ 

FDRC$A ,,256. 

FDOP$A GETLUN 

.PSECT INPBUF,D,GBL 

.BLKB 5 

.BYTE 11 

BUFl: : 

.BLKB 256. 

.BLKB 5 

.BYTE 13 

BUF2: : 

.BLKB 25b. 

.END 


2. Assemble the Patch: 

MAC IOPRT.POB-IOPRT.PAT 


3. Extract the original module from the PRT library: 
LBR IOPRT-PRT/EX:IOPRT 

4. Patch the module 


PAT IOPRT;2-IOPRT;1/CS:061561,IOPRT.POB/CS:014463 

5. Replace the module in the library 
LBR PRT/RP-IOPRT 

6. Rebuild PRT with the latest version of your RSX system 
TKB @PRTBLD 


Correction to Fortran-77 OTS for 
I/D Tasks Using Virtual Arrays 


Gary L. Maxwell 
Lawrence M. Baker 

U.S. Geological Survey 
Menlo Park, California 


In the course of our separate investigations on using PLAS 
directives and in developing Supervisor mode libraries, we have 
discovered a bug in the Fortran-77 V5.0-12 OTS. Symptoms of the 
bug include a "Virtual array initialization failure" message from 
Fortran or a segment fault caused when virtual arrays are first 
accessed by an I/D space task. This problem can occur when the 
Instruction Space of the task is between 28K and 32K words in 
length, or when a resident library (such as FCSRES) is linked into 
the I/D task using APR 7. 

The following program will exhibit the problem: 

File TSTBUG.FTN: 

Program TSTBUG 
C 

Virtual Ivfill(8192) 

C 

Do 1000 I - 1, 8192 
Ivfill(I) - I 
1000 Continue 

Do 2000 I - 1, 8192 

If (Ivfill(I) .ne. I) Stop 'Verify error' 
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2000 Continue 
Stop 
End 


When the OTS is corrected, the program example above will work 
correctly. 


File FILLIS.MAC: 


Correction file VINIT.PAT: 


.title fillis 

Build a 28 KW instruction space array 


.Title $VINIT 
.Enabl Lc 
.Ident /F7705Z/ 


.psect fcode,i,ro 

.blkw 28.*1024. ; Load it up, folks 

. end 

Compile, assemble, and build as follows: 

>F77 TSTBUG-TSTBUG/TR:ALL 

>MAC FILLIS*FILLIS 

>TKB TSTBUG/ID-TSTBUG,FILLIS 


; VINIT.PAT — Correction for F77 OTS module $VINIT 
; (Original Ident: F77005) 

; 

; Corrections: 

; GMLB01 — Use Wi. EDS bit mask to set up mapping 

; in I-space for non I/D tasks and D-Space 

; for I/D tasks. 

; Original file checksum: 25372 
; Correction file checksum: 5712 


The above program will fail with a Virtual array initialization 
error. 


.Mcall Wdbdf$ 


The problem is due to an error in the Fortran OTS routine $VINIT. 
When the Virtual array PLAS window is created, Fortran uses 
information provided by the Task Builder to determine which APR to 
use to map the Virtual array window. For I/D space tasks, the Task 
Builder correctly determines which D-Space APR should be used by 
Fortran for Virtual arrays. However, Fortran does not make any 
distinction between I/D and non-I/D tasks. Fortran will always 
attempt to map the Virtual array in I-Space. 

For I/D tasks that are not using APR 7 for instructions or data. 
Virtual arrays still work correctly. This is because the Executive 
will automatically map the D-Space APR along with the I-Space APR 
if the D-Space APR is not currently in use. However, if the task 
uses APR 7 for instructions, or is mapped to a resident library 
through APR 7, Fortran will try to remap APR 7 I-Space, causing an 
eventual failure. 


The correction to $VINIT which follows will work regardless of 
whether a task is or is not built as an I/D space task. This is 
possible by the use of an undocumented bit mask in the status word 
of the Window Definition Block, WS.EDS (Effective Data Space). 
This mask is the sum of WS.UDS (User Data Space) and WS.SIS 
(Supervisor Instruction Space). When used, the M-Plus Executive 
will map the window based on whether the task uses Data Space: if 
it does, the window is mapped in D-Space; otherwise, the window is 
mapped in I-Space. 


Wdbdf$ ; Window Definition Block Offsets 

.Psect $$OTSI,CON,RO,REL,LCL,I 

$$$ - . 

.«$$$+ 62 


Mov 

. End 


#<WS.64BIWS.MAP 1WS.EDSIWS,WRT>,(r0) + 
; Store window status 


To correct the OTS, follow the instructions in the Fortran-77 
Installation Guide, or use the following command sequence: 


>LBR VINIT.OBJ;1—SYSLIB/EX:$VINIT 
>MAC VINIT.POB-VINIT.PAT 

>PAT VINIT.OBJ;2*VINIT.OBJ;1/CS:025372,VINIT.POB/CS:005712 
>LBR SYSLIB/RP*VINIT.OBJ;2 
Module "$VINIT" replaced 

> 


RSX—9 


RSX-10 




RSX MULTITASKER 


User Written Drivers and RMS Block Locking ?? Il 


Carl T. Mickelson 
Goodyear Aerospace Corporation 
Akron, Ohio 44315 


For those of you who write your own RSXll-M device drivers, here is 
a review of another "gotcha" of RSX. In the module IOSUB after the 
label $IOFIN, there exists the following sequence of instructions: 


.IF DF 

R$$LKL 

MOV 

I.PRM+16(R3),RO 

BEQ 

20$ 

CMP 

R0,#140000 

BHIS 

20$ 

DEC 

(R0) 

20$: 


. ENDC 


This code will 

decrement memor; 

I.PRM+16 of 

a finished 10 

circumstances: 



; If RMS block locking in the exec 
;Get last parameter from 10 packet 
;If its zero, continue below 
;If a KAPR 6 buffer address 
/continue below 

/else, decrement memory at (RO) 


request under the following 


Your system supports RMS-11 block locking, and l.PRM+16 
is non-zero and not a kernel APR 6 data buffer virtual 
address. 


Should a user written driver use all eight available words in the 
parameter portion of an 10 packet for its own purposes (QIO 
functions marked as control functions, or functions requiring 
multiple data buffers, etc), the I.PRM+16 word of the 10 packet 
should be cleared before calling $I0D0N, $I0ALT, or $I0FIN. 
Otherwise some random location in executive address space will be 
decremented any time such a QIO is completed. Presuming that R5 
points at the device UCB,the following code will clear the required 
word before returning to the executive: 
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We experienced this "gotcha" when a user program odd-address 
trapped. It just so happened that our device driver left the value 
4 in I.PRM+16 for some QIO functions. This caused address 4, the 
odd-address trap vector, to be corrupted and when the user program 
trapped, the exec couldn't recover. Worse yet, when location 4 was 
odd (50% of the time), the CPU, an ll/34a, would keep trapping, 
until a fatal stack error occurred. This wiped out all the 
interrupt vectors, making it impossible to take a crash dump. The 
symptoms looked at the time like a hardware device was holding a 
UNIBUS signal (SSYN) off, continuously causing the CPU to trap! 

What was actually happening follows. The processor kept trapping 
to 4 because location 4 was odd, filling the stack until location 
177776 was to be written. At this point, the ll/34a trap 
micro-code hung on non-existent memory, making it impossible to 
halt the processor without forcing maintenance mode on the 
programmers console and executing a micro-step halt. 


SEE Utility 


Michael E. Mazzoni 
Process Control Systems, Inc. 
1300 S. Calhoun Road 
Brookfield, WI 53005 


SEE as a small debugging aid has been written to permit real-time 
display (a la RMDEMO) of the octal contents of any location in core 
of the machine it is running in, I/O page, executive, or any task 
or partition. At 1/10 second intervals, it opens the block of core 
specified and, if any changes have occurred since the previous 
snapshot, it updates the display on the VT-52 terminal. It runs 
under any RSXllM mapped system. 


.IF DF 

R$$LKL 

/If RMS block locking in the exec 

MOV 

R5,-(SP) 

/Save UCB address 

MOV 

U.SCB(R5),R5 

/Get SCB address 

MOV 

S.PKT(R5),R5 

/Get IO packet address 

CLR 

I.PRM+16(R5) 

/Clear last parameter 

MOV 

.ENDC 

(SP)+,R5 

/Restore UCB address 

CALL 

$IODON 



Up to 256 bytes of core can be displayed. This can be located in 
as many as 8 separate areas, with actual displayable sizes limited 
by the screen capacity. The display in each area can be in word, 
byte or character mode. 

The user can move the windows around with simple octal commands at 
any time while running. It is oriented toward displaying a module 
(with its assembler relative addresses) at a location within a task 
partition, although absolute display of the effective addresses can 
also be done. 
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The program keeps a copy of the content of each location to be 
displayed in an internal buffer. Each tenth second, in a fast 
loop, it copies the displayed words to another buffer as a 
snapshot. Then, after restoring its mapping to normal, it compares 
the two buffers. Only those words which have changed since the 
last snapshot will be displayed. If a slow (1200 baud) terminal is 
used to display a large rapidly changing display, the one tenth 
second sampling rate will not be achieved due to the time required 
to update the terminal display. Thus the tenth second update rate 
is a maximum, only achieved with fast terminals or slowly changing 
data. 

On very active displays, CTRL S and CTRL Q can be used in the usual 
way to freeze the data, if needed. On inactive displays (not much 
changing in the core being watched) the CRT cursor will be 
immediately after the last word changed. 

SEE is found on the Fall, 1981 RSX SIG tape in UIC [343,70]. 

There is one easily fixed bug in SEE: it doesn't work on RSX-11M+ 
systems with I/D space mapping. However, a one line change to the 
MACRO code will make it work. Details: 

1 . 

About 80 lines from the start of SEE.MAC, the symbol UDSARO is 
defined (the original definition works for any RSX-11M system 
or M+ w/o I/D space). Locate this symbol. 

2 . 

Change the value of UDSARO from 177640 to 177660 for an 
RSX-11M+ system with I/D space. 177640 is the user mode 
INSTRUCTION space page address register number 0 of the KTll 
memory management unit. For an M+ system with I/D space the 
SEE program needs the data mapped by 177660, the user mode DATA 
space page address register number 0. 

3. 

Re-assemble and re-taskbuild. 


This modified SEE has been in use at PCS for several years, and has 
been tested on RSX-11M+ vl.0, v2.0, v2.1, and v3.0. 

This very useful RSX utility was written by: 

Jack Harvey, Vice President 
National Data Systems 
299 Market Street 
Saddlebrook, NJ 07662 
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HOW TO USE THE RSX 
FULL-DUPLEX TERMINAL DRIVER 
WITH TERMINALS 


Dale R. Donchin 

Digital Equipment Corporation 


GENERAL TERMINAL QIO FORMAT 


MACRO-11 

QIO$ FUAT77TOV,LUN,FLAG,,SrA7T/S, AST, < PARAMETERS > 

WHERE FUNCTION IS ONE OF: 

IO.ATT IO.DET 

IO.RLB IO.WLB 

IO.RVB IO.WVB 

SF.GMC SF.SMC 

IO.RPR IO.RTT 

IO.EIO IO.HNG 

STATUS IS THE ADDRESS OF 
A TWO-WORD STATUS BLOCK 

PARAMETERS IS A LIST OF UP TO SIX 
PARAMETERS DEPENDENT ON THE FUNCTION 


FORTRAN 

CALL QIO (FUNCTION,LUN , FL AG ,,STATUS, PARAMETERS) 

WHERE FUNCTION IS AN INTEGERS VARIABLE EQUAL 
TO THE APPROPRIATE FUNCTION CODE 

STATUS IS A TWO ELEMENT INTEGERS ARRAY 

PARAMETERS IS A SIX ELEMENT INTEGERS ARRAY 
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EXAMPLES I 


MACRO-11 

QIOW$ IO.ATT, 5, 1„ IOSB 
QIOW$ IO.DET, 5, 1„ IOSB 
QIOW$ IO.RVB, 5, 1„ IOSB,, <IBUF, ILEN> 

QIOW$ IO.WVB, 5, 1„ IOSB,, <OBUF, OLEN, OVFC> 


FORTRAN 

PARAMETER IOATT = 1400 

PARAMETER IODET = 2000 

PARAMETER IORVB = 10400 

PARAMETER IOWVB = 11000 

CHARACTERS IBUF, OBUF 
DIMENSION IOSB(2), IPARAM(6) 

BYTE IOSBP(4) 

EQUIVALENCE (IOSB(l), IOSBP(l)) 

CALL WTQIO (IOATT, 5, 1„ IOSB,, IDSW) 

CALL WTQIO (IODET, 5, 1„ IOSB,, IDSW) 

CALL GETADR (IPARAM(l), IBUF) 

IPARAM(2) = 80 

CALL WTQIO (IORVB, 5, 1„ IOSB, IPARAM, IDSW) 

CALL GETADR (IPARAM(l), OBUF) 

IPARAM(2)=80 
IPARAM(3)= 7 40 

CALL WTQIO (IOWVB, 5, 1„ IOSB, IPARAM, IDSW) 
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QIO$C 

QIO$C 


EXAMPLES II 

MACRO-11 

IO.RPR, 5, 1„ IOSB,, < IBUF, ILEN,, OBUF, OLEN, OVFC> 
IO.RTT, 5, 1„ IOSB,, <IBUF, ILEN,, TTABLE> 


FORTRAN 


PARAMETER IORPR = 4400 

PARAMETER IORTT = 5001 

INTEGERS TTABLE(16) 

DATA TTABLE/16*0/ 

CHARACTER*80 IBUF, OBUF 
DIMENSION IOSB(2), IPARAM(6) 

BYTE IOSBP(4) 

EQUIVALENCE (IOSB(l), IOSBP(l)) 

CALL GETADR (IPARAM(l), IBUF) 

IPARAM(2) = 80 

CALL GETADR (IPARAM(4), OBUF) 

IPARAM(5) = 80 
IPARAM(6) = "40 

CALL QIO (IORPR, 5, I„ IOSB, IPARAM, IDSW) 

TTABLE(l) = '20210 

CALL GETADR (IPARAM(4), TTABLE(l)) 

CALL QIO (IORTT, 5, 1„ IOSB, IPARAM, IDSW) 
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EXAMPLES III 

MACRO-11 

BUFFER:.BYTE TC.TTP, 0 

.BYTE TC.SLV, 0 

LENGTH = . - BUFFER 

QIO$C SF.GMC, 5, 1„ IOSB,, <BUFFER, LENGTH> 
QIO$C SF.SMC, 5, 1„ IOSB,, < BUFFER, LENGTH> 


FORTRAN 


PARAMETER SFGMC = 2560 

PARAMETER SFSMC = 2440 

PARAMETER TCTTP = 10 

PARAMETER TCSLV = 50 

BYTE BUFFER(4) 

DIMENSION IOSB(2), IPARAM(6) 

BYTE IOSBP(4) 

EQUIVALENCE (IOSB(l), IOSBP(l)) 

BUFFER(l) = TCTTP 
BUFFER(3) = TCSLV 

CALL GETADR (IPARAM(l), BUFFER(l)) 
IPARAM(2) = 4 

CALL QIO (SFGMC, 5, 1„ IOSB, IPARAM, IDSW) 
CALL QIO (SFSMC, 5, 1„ IOSB, IPARAM, IDSW) 
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SUBFUNCTIONS 


READ 

TF.RAL 

READ PASS-ALL 

TF.RNE 

READ WITH NO ECHO 

TF.RST 

READ WITH SPECIAL TERMINATOR 

TF.TMO 

READ WITH TIME-OUT 

TF.XOF 

READ FOLLOWED BY XOFF 


WRITE 

TF.CCO 

WRITE AND CANCEL X) 

TF.RCU 

WRITE AND RESTORE CURSOR 

TF.WAL 

WRITE PASS-ALL 

TF.WBT 

WRITE BREAK-THROUGH 


ATTACH 

TF.AST 

ATTACH FOR UNSOLICITED INPUT 

TF.NOT 

ATTACH FOR INPUT NOTIFICATION 

TF.XCC 

ATTACH FOR INPUT EXCEPT C 

TF.ESQ 

ATTACH FOR ESCAPE SEQUENCES 


READ AFTER PROMPT 

TF.BIN 

READ WITH PASS-ALL PROMPT 

NOTE: SUBFUNCTIONS CAN ONLY BE USED 

WITH 

LOGICAL I/O FUNCTIONS 
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EXTENDED I/O 


MACRO-11 



MODIFR 

= TF.RPR ! TF.RDI ! 

TF.RTT ! 

TF.TMO 

ILIST: 

.WORD 

MODIFR, 

0 



.WORD 

IBUF, 

ILEN, 

TIMOUT 


.WORD 

OBUF, 

OLEN, 

OVFC 


.WORD 

TTABLE, 

TTABLN 



.WORD 

DEFBUF, 

DEFLEN 


ISIZ = 

. - ILIST 




DEFBUF: 

.ASCII 

/Default input/ 




QIO$C 

IO.EIOITF.RLB, 5, 1„ 

IOSB,, < ILIST, ISIZ> 


FORTRAN 

PARAMETER IOEIO = 17400 

PARAMETER TFRLB = 2 

PARAMETER TFRNE = 20 

CHARACTER*80 IBUF 

DIMENSION IOSB(2), IPARAM(6), ILIST(24) 

CALL GETADR (IPARAM(l), ILIST(l)) 

IPARAM(2) = 24 

ILIST(l) = TFRNE 
ILIST(2) = 0 

CALL GETADR (ILIST(3), IBUF) 

ILIST(4) = 80 

CALL QIO (IOEIO + TFRLB, 5, 1„ IOSB, IPARAM, IDSW) 
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TYPEAHEAD 


CIRCULAR BUFFER 

ONE PER TERMINAL, SETTABLE PER TERMINAL 
MUST BE ENABLED WITH ATTACH OR SERIAL MODE 
INPUT SAVED UNTIL: 

READ POSTED 
AST GIVEN 
FLUSH QIO 

ERROR ENCOUNTERED 
"C ENTERED 
"X ENTERED 

FIXED SIZE FOR NON-I/D-SPACE SYSTEMS 
(ALLOCATED FROM DRIVER OR PRIMARY POOL) 
VARIABLE SIZE FOR l/D-SPACE SYSTEMS 
(ALLOCATED FROM SECONDARY POOL) 

BELL SOUNDED WHEN OVERFLOW OCCURS 

NEW SETTABLE HOST AND TERMINAL SYNCHRONIZATION 

CAN POLL TO SEE IF NON-EMPTY 

OR QUEUE AN AST 
OR READ CONTENTS 


RSX-21 


MODEM SUPPORT I 

LOCAL 

TC.DLU =0 OR SET NOREMOTE COMMAND 
DTR AND RTS DISABLED (DATA ONLY) 

DIAL-IN AND DIAL-OUT CALLERS NOT RECOGNIZED 
ALL QIO FUNCTIONS ALLOWED 

REMOTE 

TC.DLU = 1 OR SET REMOTE COMMAND 
DTR AND RTS ENABLED 
DIAL-IN CALLS ACCEPTED 

ATTACT/DETACH/CHARACTERISTIC QIOS ALLOWED 
READ/WRITE ALLOWED WHEN A CONNECTION IS MADE 

DON’T CALL US, WE LL CALL YOU 
TC.DLU = 2 (NO COMMAND LEVEL INTERFACE) 

DTR AND RTS ENABLED 

DIAL-IN AND DIAL-OUT CALLS ACCEPTED 

ALL QIO FUNCTIONS ALLOWED 


RSX-22 





MODEM SUPPORT II 


WHEN A CALL IS ANSWERED: 

TERMINAL TYPE SET TO UNKNOWN 
BUFFER WIDTH SET TO 72 CHARACTERS 
MCR SET AS THE CLI 

LOWERCASE TO UPPERCASE CONVERSION FORCED 
MANY CHARACTERISTICS RESET 

REMOTE SPEED SET OR AUTO-BAUD PROCESS BEGUN 

WHEN A CALL IS TERMINATED: 

TYPEAHEAD BUFFER FLUSHED 
ALL ACTIVE I/O IS ABORTED 
USER IS LOGGED OUT 

DTR/RTS MODEM SIGNALS ARE CYCLED OFF AND ON 
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ESCAPE SEQUENCES 


USE 

ALLOWS COMMUNICATION OF CONTROL 
INFORMATION AS PART OF THE DATA STREAM 

GENERATED BY: 

FUNCTION KEYS 

CURSOR CONTROL KEYS 

NUMERIC KEYPAD IN ALTERNATE MODE 

TERMINAL INQUIRIES 

APPLICATION TO CONTROL TERMINAL 


FORMAT 

ESCAPE CHARACTER FOLLOWED BY OPTIONAL 
INTERMEDIATE PARAMETERS AND TERMINATED 
BY A REQUIRED FINAL CHARACTER 


ACTIVATION 

SET TC.ESQ TERMINAL CHARACTERISTIC 
ATTACH TERMINAL WITH TF.ESQ SUBFUNCTION 

OR 

(NEW WITH V3.0) READ WITH TF.RES SUBFUNCTION 
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ADVANCED FUNCTIONS 

FULL-DUPLEX MODE 
SIMULTANEOUS READS AND WRITES 
REAL-TIME CONTROL 
SPLIT-SCREEN APPLICATIONS 

CURSOR POSITIONING 
DEVICE INDEPENDENCE 
POSITION CURSOR BEFORE OUTPUT 
CLEAR SCREEN BEFORE OUTPUT 
RESTORE CURSOR AFTER OUTPUT 

V3.0 NEW READ SUBFUNCTIONS 
READ PASS-THRU 
READ DEFAULT INPUT 
READ TYPEAHEAD BUFFER 

V3.0 NEW ASTS 

MODEM HANGUP NOTIFICATION 
TERMINAL MANAGEMENT MODE 
DEFINABLE OUT-OF-BAND CHARACTER AST 


BUFFERED I/O 


ALLOWS TASKS WITH OUTSTANDING 
I/O TO REMAIN CHECKPOINTABLE 

ONLY AFFECTS ACTIVE REQUESTS 

BUFFERS ARE ALLOCATED FROM TERMINAL 
DRIVER PRIVATE POOL OR PRIMARY POOL 

BUFFERS ARE FIXED IN SIZE AND 
ARE ALLOCATED AS NECESSARY 

READS MAY BE BUFFERED OR UNBUFFERED 

WRITES ARE ALWAYS BUFFERED 

DMA IS DONE A BUFFER AT A TIME 
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SECNDS Subroutine 


John M. Crowell 
Crow4ell,Ltd.* 

145 Andanada 
Los Alamos, NM 87544 
(505) 662-3893 


The SYSLIB function subroutine SECNDS returns only an integer number of 
elapsed seconds. The following subroutine is offered as a replacement. It 
returns fractional values of seconds, truncated to the last clock tick. An 
optional section of code is included to accomodate both 50 Hz and 60 Hz line 
clocks. The code is position-independent, so it can safely be used in system 
and foreground jobs. 

The assembly conditional FPU$$ must be non-zero if this routine is to replace 
the SECNDS routine for FORTRAN-77. It may be set non-zero if the FORTRAN-IV 
usage is strictly for processors with the floating-point instruction set 
(FPU). Otherwise, if FPU$$ is zero or undefined, the assembly will assume 
that SYSLIB function AJFLT and FORTRAN-IV OTS routines DIF$SS and SUF$SS are 
available. 

If you have any problems with this routine, please send their description to 
me in writing. I tend to get rude and sarcastic on the phone! 


* but not very 


.ENABL MCL 

.MODULE SECNDS,RELEASE=JMC,VERSION=01,COMMENT=<Returns Time-of-day>,LIB=YES 
; T1 - SECNDS( TO ) 

; Returns (time of day - TO) in seconds (Floating Point) 

; Unlike SECNDS routine distributed in RT-11 SYSLIB, this routine returns 
; fractional values. Resolution is one clock tick. 

; If this routine is to be used with FORTRAN-77, the conditional FPU$$ 

; MUST be non-zero. (i.e. delete the semicolon in the following line.) 

;FPU$$=1 

; If this routine is to be used exclusively in FORTRAN-IV systems with 
; floating-point instruction set (FPU - not FIS), the semicolon may be 
; removed. 

.IIF NDF FPU$$, FPU$$ = 0 

.PSECT SYS$I 

.IF NE FPU$$ 

F0=%0 
. IFTF 

SECNDS:: 

. IFT 



STFPS 

SETF 

-(SP) 

; Save Floating Point Status 


SETL 


; Time-of-day is long ingeter 

IFF 

MOV 

R5,-(SP) 


IFTF 

CMP 

-(SP),-(SP) 

; Here's where it goes 


MOV 

SP, R0 

; MOV SP,-(SP) is processor dependent 


MOV 

R0,-(SP) 

; Set up .GTIM argument block 


MOV 

#21*400,-(SP) 



MOV 

SP ,R0 



EMT 

375 

; .GTIM 


CMP 

(SP)+,(SP)+ 

; Ignore argument block 

IFT 

LDCLF 

(SP)+,F0 

; Convert ticks to floating point 

IFF 

MOV 

(SP)+,R0 



MOV 

(SP)+,R1 



MOV 

R0,-(SP) 



MOV 

Rl,-(SP) 



MOV 

SP, R0 



MOV 

R0,-(SP) 



MOV 

#1,-(SP) 



MOV 

SP, R5 



JSR 

PC,AJFLT 

; Convert ticks to floating point 


ADD 

#8. ,SP 



MOV 

(SP)+,R5 



MOV 

Rl,-(SP) 



MOV 

R0,-(SP) 



CLR 

-(SP) 



.IFTF 


♦but not very. 
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If you want to get fancy, you can allow for both 50Hz and 60Hz line 
clocks by including this code. You'll probably want to omit it. 



CONFIG 

= 300 



CLK50$ 

- 40 



MOV 

#C0NFIG,-(SP) 



MOV 

#34*400,-(SP) 



MOV 

SP,R0 



EMT 

375 

; Get configuration word 


CMP 

(SP)+,(SP)+ 



BIT 

#CLK50$,R0 

; 50 Hz clock? 


BEQ 

1$ 


. IFT 

DIVF 

#50.,F0 

; Divide by 50 to get seconds 

.IFF 

MOV 

# a F50.,R4 

; 50 ticks/sec 

. IFTF 

BR 

2$ 


1$: 





.IFT 

DIVF 

#60.,F0 

; Divide by 60 to get seconds 

.IFF 

MOV 

# a F60.,R4 

; 60 ticks/sec 

.IFTF 




2$: 




.IFT 

SUBF 

@2(R5),F0 

; Subtract TO 


STF 

F0,-(SP) 

; Put result on stack 

• IFF 

JSR 

R4,@(PC)+ 

; Divide to get seconds 


.WORD 

DIF$SS 



.WORD 

.+2 



MOV 

2(R5),R4 



MOV 

2(R4),-(SP) 



MOV 

(R4),R4 



JSR 

R4,@(PC)+ 

; Subtract TO 


.WORD 

SUF$SS 



.WORD 

.+2 


.IFTF 

MOV 

(SP)+,R0 

; Return as floating-point function 


MOV 

(SP)+,R1 


.IFT 

LDFPS 

(SP) + 


.ENDC 

RTS 

PC 



.END 




Announcing BASIC-PLUS/RT-11 


Digital is announcing a new release of BASIC on RT-1 1 called 
BASIC-PLUS/RT-11 V3.0. A follow-on product to BASIC-11/RT-l1 V2.1, 
BASIC-PLUS/RT-1 1 V3.0 is an interactive, incremental compiler 
operating under the RT-11 Operating System. It is based upon 
BASIC-PLUS, the popular and widely-used BASIC language supported with 
Digital's RSTS/E Operating System. The significantly enhanced 
features and functionality of Version 3.0 make it an attractive choice 
for technical, commercial and educational applications. In addition, 
a level of compatibility has been attained between the BASIC products 
on RT-11, RSTS/E and VAX/VMS which enables users to migrate BASIC 
applications back and forth among all these system environments. 

Some of the product features available with BASIC-PLUS/RT-11 V3.0 
include: 

- Incremental compilation 

- Multi-statement lines, multi-line statements 

- 31 Character variable and function names 

- Statement modifiers 

- Support for manipulation and testing of logical values, and for 
manipulation of integers at the bit level 

- Block I/O, including direct access to individual blocks of a disk 
file 

- IF... THEN... ELSE and other extended, flow-control constructs 

- Programmable error handling 

- Mechanisms for control of arithmetic precision: scaled arithmetic 
and string arithmetic 

- Matrix manipulation operations 

- New, re-organized documentation 

- Line-by-line comments 

- Extended debugging aids: BRAKE and TRACE commands 

- Logical expressions 

- Multi-line function definitions 

- Alias, to improve upward and backward compatibility 

- 6 New commands 

- 13 New statements 

- 7 New operators 

- 37 New built-in functions 

BASIC-PLUS/RT-11 Version 3.0 and BASIC-PLUS/RT-11 on the Professional 
Version 3.0 will be available in February, 1986. Contact your local 
sales or service representative for pricing and ordering information. 


Order Number 


QJ913-UZ BASIC-PLUS/RT-1 1 

QY913-UZ BASIC-PLUS/RT-11 


QB913-A3 BASIC-PLUS/RT-11 

on the Professional 


Single-Use License Category H 
Single-Use License Category L 

License, Documentation and 
Media 
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CASE WESTERN RESERVE UNIVERSITY • CLEVELAND, OHIO 44106 



January 24, 1986 


Bill Leroy 

The Software House, Inc. 

470 E. Paces Ferry Road Park 
NE 1020 
P.0. Box 52661 
Atlanta, Georgia 30355 



Dear Bill: 


I recently submitted a curve-fitting program DISCRETE for the 
DECUS library. This program by Steve Provencher extracts the 
parameters for any exponential decay process and is by far the best 
available. Marilyn Gervais at DECUS tells me it should be out in a 
month. 


I thought this brief description would alert potential users to 
its availability under RT-11. The sources are in FORTRAN IV and can 
be adapted to RSX etc. It is available directly from Dr. Provencher 
for the VAX, I believe. 


Yours truly. 



Tomuo Hoshiko, Ph.D. 
Professor 


TH/jsr 

Enclosure 


School of Medicine 
Department of Physiology 
2119 Abington Road 
Telephone: 368-3400 
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DISCRETE, S.W.Provencher'8 program to fit a sum of exponentials. 

by T. Hoshiko, Dept, of Physiology 

Case Western Reserve University School of Medicine 
Cleveland OH 44116, U.S.A. 

One of the most difficult but seemingly easy curve-fitting 
tasks is to fit a sum of exponentials of the form: 
n 

Y(k) * I <x( j ) EXP(-x( j)*T(k)) 
j*0 

where k* 1,2, . . . to m points, and n is the number of ex¬ 

ponentials. This task is also one of the most common since the 
expression is a solution of linear first order processes such 
as Isotopic decay, or pharmacokinetics of drug disappearance from 
the blood stream. The program to be described, DISCRETE, written 
by Stephen Provencher, has to be one of the best if not THE BEST 
program for fitting such a curve and is now available through 
DECUS. 

Before the availability of computers, the most common method 
to resolve the components of an exponential decay curve was the 
peeling method. The data points were plotted on semilogarithmic 
paper and successive straight lines were subtracted off. Subjec¬ 
tive bias and error are inherent in this method and it was soon 
abandoned. 
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In order to fit a non-linear function the common procedure 
has been to linearize around a given point T(ko) using a Taylor's 
series expansion as a function of the fitting parameters a(j) 
and A(j) (see Bevington,1969). By taking the first term, we ob¬ 
tain an estimate of Y(k) as the product of the rate of change of 
Y at T(ko) with respect to each parameter and its corresponding 
increment a(j) ( or A(j) ). The chi square is used to estimate 
the deviation. By the method of least squares, chi square is 
minimized with respect to each parameter increment by successive 
approximation to obtain a set of parameters to best fit the data. 
The problem with this approach is that convergence to a minimum 
chi square occurs only when the initial estimates for the fitting 
parameters are very close to minimum since only first order terms 
in the expansion are used. Thus the method was combined by Mar- 
quardt with the gradient search method which approaches the 
minimum rapidly, giving the popular algorithm associated with his 
name. Although the Marquardt approach works well with many 
non-linear functions, it often tends to diverge (blow up) when 
applied to sums of exponentials. The difficulty is the 
nonorthogonal behavior of exponential functions. The end result 
is that small variations in the data lead to significant effects 
on the parameters and rather different sets of parameters can 
produce very similar values of chi square when the data are not 
extremely accurate. 

This situation led to proposals to transform the function to 
the complex plane where entirely new properties are exhibited by 


the fitting function. An exact formal solution by Fourier 
transforms is theoretically possible to give a spectrum with 
sharp peaks at each \(j). No initial guesses as to magnitude or 
number of components is needed. However, problems of truncation 
of the data and lack of accuracy has limited the usefulness of 
the initial attempts. Provencher has overcome these difficulties 
by use of specified convergence parameters and the use of a Gaus¬ 
sian taper window. In addition, noise reduction was accomplished 
by autocorrelation data smoothing. The resulting program DIS¬ 
CRETE requires only the raw data and initial guesses as to the 
number or values of parameters are neither needed nor accepted. 
DISCRETE is designed for the automatic analysis of discrete spec¬ 
tra consisting of a sum of exponentials (up to 9) with provision 
for a possible constant term. 

The RT-11 version of DISCRETE was compressed to fit in the 
PDP-11 address space under RT-11. Input data can be either 
equally spaced in time, in which case the time points need not be 
specifically given, or at arbitrary intervals, requiring specific 
time points. I have not tried fitting more than 4 exponentials 
plus a constant and am uncertain whether the maximum of 9 ex¬ 
ponentials can be handled. It is limited to handling only 50 
data points and stores intermediate data on FORTRAN direct access 
disk files, which makes things very slow. The speed no doubt 
could be increased by using the virtual overlay feature of RT-11 
version 5, etc. 
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One feature which is a little disconcerting is the large 
amount of print out of intermediate results. If the print in¬ 
struction flags, PRL, PRPREL, PRFINL are set equal to F, there is 
no possibility of examining the intermediate results. TSX moni¬ 
tor command ASSIGN allows attaching the logical unit LP: to a 
disk file for later printout. You save a lot of paper and not 
have to leave your printer on all night. The command file 
PRVTSX.COM can be used to set this up. 

The documentation in PRVTXT.DOC applies to the RT-11 version 
which can run on V5.01C. CNote that escape sequences for summa¬ 
tion signs and underlining (pages 2,7,8,9 and 14) are for the 
LAI00 printer.3 Not included in PRVTXT.DOC but with the printed 
material are Provencher's Update2 and original printout from the 
Univac 1108 supplied by Provencher. Additional notes are in¬ 
cluded in the command files PRVBLD, PRVFOR and PRVLNK. The com¬ 
mand file PRVBLD.COM will make the ASSIGNments needed to run the 
two command files PRVFOR.COM and PRVLNK.COM which compile and 
link the programs. PRVBLD must be modified to conform to your 
volumes which hold the sources and in which you wish the *.SAV, 
etc., to be stored. 

As mentioned above I have been using TSX to run these pro¬ 
grams in order to defer printing the output. RT11 does not allow 
this kind of ASSIGN instruction and prints out the material 
directly. I have included the original UNIVAC 1108 output from 
the Provencher's first and part of the output of the second data 


set to allow verification. The first data set PRVTS1.DAT took 24 
minutes and some seconds to run and most of it was spent in 
FANLYZ. The second data set PRVTS2.DAT took almost 50 minutes. 
The output from the second data set are stored in the files 
DISCRT.Fn (n=0,5) for comparison. 


REFERENCES 

Bevington,P.R. 1969. Data Reduction and Error Analysis for the 
Physical Sciences. McGraw-Hill,New York. 336pp. 

Marquardt,D.W. 1963. An algorithm for least-squares estimation of 
nonlinear parameters. J.Soc.Ind.Appl.Math. 11(2):431-441. 

Provencher,S.W. 1976. A Fourier method for the analysis of 
exponential decay curves. Biophys. J. 16:27-41. 
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Automatic System Generation on Floppy-Based Systems 


Chapter 3 of the RT-li System Generation Guide says that it is not 
passible to perform an automatic system generation on a PDP-11 with 
only dual floppies. Since I have a MINC-23, I found that statement 
very discouraging. However, a little investigation showed that, while 
that restricton may apply to RX01 drives, the following procedure 
(based on a method developed by Mike Demers of Polaroid) makes it quite 
easy to automatically sysgen one monitor at a time with dual RX02 (or, 
apparently, RX50) floppies. (The procedure works when the reduced 
storage capacity of RX50 floppies is simulated by carrying a 188 
block dummy file on each RX02, but I don't have access to an RX50 
system to confirm this.) Read through the whole procedure once to see 
your options before you begin. 


Begin by formatting and initializing two RX02 or three RX50 diskettes: 
one will be a system diskette and the second will be a data diskette. 
(On an RX50 system, you may need two data diskettes.) Copy the 
following files (from your working system and distribution backups) to 
the system diskette: 


RT11SJ.SYS or RT11FB.SYS 
DY.SYS or DZ.SYS 
SWAP.SYS 

TT.SYS (if necessary) 

LP.SYS or LS.SYS (if appropriate) 

IND.SAV 

DIR.SAV 

PIP.SAV 

DUP.SAV 

MACRO.SAV 

LINK.SAV 

SYSMAC.SML 

SYSGEN.COM (from distribution backup vol. 3). 
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Copy the bootstrap, squeeze the diskette, then boot this system. 
(Ignore the error message that the startup file can't be found.) 

Run SYSGEN.COM as described in section 3.2 of the SYSTEM GENERATION 
GUIDE but assign diskette drive 1 (DYl: or DZ1:) for the source input 
and drive 0 for the binary and map output, and refuse to keep the 
system .OBJ files. (There is enough room to keep the answer file and 
the working files, and they are very handy.) 

When SYSGEN.COM completes, the system device should contain the files 
mentioned near the end of section 3.2. Copy SYSGEN.CND and SYSGEN.TBL 
to the (empty) data diskette (and SYSGEN.CND to the second RX50 data 
diskette, if you need one), delete SYSGEN.CND, SYSGEN.TBL, SYSGEN.COM, 
and IND.SAV from the system diskette, and squeeze the system. (Ignore 
the "start file not found" error message again.) 

TYPE or PRINT SYSGEN.MON and SYSGEN.DEV as indicated in section 3.3.1 
to determine just what source files MACRO will require. Copy these 
.MAC files, and only them, from distribution backup diskettes 4 and 5 
to the data diskette then squeeze it, if necessary. (If all the 
required source files won't fit on a single RX50 diskette, put the 
files needed by SYSGEN.MON on the diskette containing SYSGEN.TBL and 
the files needed by SYSGEN.DEV on the other data diskette.) 
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fttit the PROPOSED VAX/RT REAL-TIME OPERATING SYSTEM «**« 


DECUS UK "RTSIG" REPLY TO THE DECUS USA RT-11 SIG VAX/RT POSITION PAPER 


•ftftft INTRODUCTION **** 


If you are using a single data diskette, put it in drive 1 and the 
system diskette in drive 0, type SSYSGEN.BLD, and go away for about 45 
minutes. When you come back, all the nasty stuff through the LINKing 
of files in section 3.4.2 will have been done by your trusty PDP-11. 

(If two RX50 data diskettes were required, you’11 have to put the 
first data diskette in drive 1 then type $@SYSGEN.MON. When that 
command file finishes (after about a half hour), put the second data 
diskette in drive 1 and type $@SYSGEN.DEV. A little more involved, but 
much easier than the procedure described in the manual.) Just backup, 
store, rename, and reorganize the files as indicated in the second 
half of section 3.4.2 and you're all done in about an hour and a half 
total time, including the time to a..swer the sysgen questions. 

If your generated system is so large that you get a device full error 
during LINKing, simply edit the SYSGEN.MON file to assign drive 1 as 
the MAP: device (doubling the space available for the monitor) and, 
depending on whether your time is more valuable than clock and system 
time, either delete the .OBJ files and restart SYSGEN.BLD or type in 
the LINK and DELETE commands from SYSGEN.MON then type $0SYSGEN.DEV to 
generate the device handlers. (With the reassignment of the MAP: 
device, you will almost certainly need a second data diskette on an 
RX50 system.) 


This paper is a reply to the DECUS RT-11 SIG paper from the USA based 
on the "Murphy" meeting held at Albuquerque on March 22, 1985. The input to 
this document has come from UK users and was formulated at a meeting held in 
London on July 15, 1985. (An additional, written, technical contribution to 
the discussion at this meeting from Ian Hammond of Hammond Software (UK) Ltd 
is gratefully acknowledged and attached in an appendix). The format of this 
document is similar to that of the "Murphy" document with the exception of an 
additional section at the beginning to justify the need for VAX/RT, followed 
by a list of those architectural features of the proposed operating system 
that were felt to be fundamentally necessary. The remainder of the document 
deals with features of VAX/RT that are deemed essential on first release 
followed by a general conclusion. 

Any correspondence relating to this document should be addressed to 
the "RTSIG" Chairman, Lawrie Godfrey, at DECUS UK, P.O.BOX 53, READING, BERKS 
RG2 OTW, UK. 

ftftftft T he NEED FOR VAX/RT »*** 

When PDP-11 1 s were introduced they were relatively expensive. Now they 
are relatively much cheaper. The same thing will happen to the VAX range. We 
have observed part of this process already which has reached the MicroVAX II 
stage. By this time next year significant further progress along this path 
will undoubtedly be visible to the ordinary user. The key difference between 
the PDP-11 development and the VAX development in software terms is that when 
the PDP-11 emerged operating system concepts were in a very raw state. Hence a 
number of parallel lines of development occurred. Also the true development 
costs of operating systems were not known. When the VAX hardware was developed 
it was in full knowledge that the hardware and software form an operating 
combination. Also that the whole process was now known to be so expensive as 
to prohibit parallel lines of software development. Hence VMS. The VMS 
operating system is excellent. It does (almost) everything. It is necessarily 
complex and this means that it is overcomplex for the user who wishes to 
interact more directly with the operating system and the hardware. Eventually 
the VAX hardware/firmware will become available to a much larger spectrum of 
users as the price and physical size fall. Where is the operating system for 
the hardware based user interested in real-time activities ? If DEC do not 
provide such an operating system then someone else will. This will not 
necessarily be to the benefit of the user community as previous experience has 
shown. VMS is a "standard" in all senses of the word, to the credit of DEC. 
VAX/RT could also be a similar "standard" of equal credit. 

Cost is an important factor. There are two costs. The cost to DEC to 
develop VAX/RT and the selling cost to the user. It is unrealistic to expect 
ordinary members of DECUS to be able to present marketing plans which show 
that VAX/RT is a commercial proposition. Indeed we doubt whether any plan of 
this nature can be accurate since few market analyses for a decade ahead have 
been shown to be correct a decade later. Statistically there is a low 
probability of getting such a forecast right based on past experience. The 
marketing faction will disagree. That is natural. Who could have forecast in 
1975 that RT-11 would have numerically outsold all other DEC operating systems 
a decade later ? 
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The second cost is the cost to the user. Eventually there will be a 
spectrum of VAX hardware from very large expensive systems down to much lower 
level systems. Ordinary users can only guess at the lowest level at which 
VAX f s will be used. Perhaps they will not be used in washing machines, but 
they might be used as home computers or small industrial controllers. The 
point is that cost of the operating system, and VAX/RT would be the operating 
system of choice, would be important. We believe that an initial pricing at 
the RT-11 level is sensible. Another important factor is the cost of layered 
software. This would also need to be priced at a lower level than the 
corresponding VMS software. 

To turn to slightly less general matters. DEC has achieved an 
impressive penetration into the scientific/laboratory/academic area. Although 
there is undoubtedly much more revenue in the business area, the scientific 
area and it»s industrial connotations cannot be ignored. A software upgrade 
path onto the VAX hardware is needed that mimics the performance and 
facilities of RT-11 but on 32 bit systems. The sales potential is obvious. A 
very large number indeed of scientific users use or know RT-11. What is this 
group looking for in general ? There are three main areas, the first of which 
is self evident :- 

ONE - The abolition of the 16 bit addressing limit. The ability to run very 
large programs written in scientific languages, of which FORTRAN is (still) 
the prime example. Perhaps not so obvious, the ability to map large areas of 
memory for dual use between VAX/RT and external devices, bit-mapped graphics 
devices are the obvious example. The ability to "throw-away" the operating 
system if necessary, whilst still being able to recall it as needed. RT-11 is 
very good in this area. 

TWO - The lowest possible interrupt latency. Or, to put it another way, the 
highest possible rate of response of the operating system to external events, 
whether these are generated via peripherals or special purpose interfaces. 

THREE - Minimal complexity of operating system software. It should be possible 
for ordinary technically competent users to boot the system immediately on 
delivery, to be doing useful work in a few days and after some time to write a 
device driver. All of this is commonplace under RT-11. System manager should 
be a non-existent post on VAX/RT sites. 

Most importantly, it is not necessary that VAX/RT should be a clone of 
RT-11 but that rather it should embody the same philosophy as RT-11. 

t«*ft THE FUNDAMENTALS OF VAX/RT *•*« 

The UK "RTSIG" see the following as vital :- 

VAX/RT should be a single user multi-tasking real-time operating system. 

VAX/RT should be designed with networking capability as an integral part of 
the design. On release it must support DECNET as an end node and eventually 
support the full OSI protocol as a through node. 

VAX/RT should support paging jobs on first release, mainly for those who want 
to write huge FORTRAN programs that exceed the size of the installed memory, 
but it is important that the paging feature can be excluded or turned off. 


VAX/RT should make extensive use of ancillary control processors (ACP's) to 
support file structures on I/O devices. By this means any file structure can 
be supported. The fullest documentation of this feature should be provided so 
that users may write their own ACP's. On first release the RT-11 and VMS 
(Files-11) ACP’s should be supported. No attempt should be made to devise a 
special or extended file structure for VAX/RT based on any other file 
structure, if required this will come later as a result of user pressure or 
being user-written. The executive should contain the basic mechanisms that 
interface to ACP f s so that users who wish to bypass ACP's can do so. ACP's 
must also contain enough functionality to enable PIP, DUP, DIR etc (or their 
VAX/RT equivalents) together with any user programs that support wildcards etc 
to be ACP independent.ACP’s all work through the same device drivers, and it 
should be possible to have different units on the same controller (and hence 
driver) to be mounted with different ACP’s. 

VAX/RT should not implement sophisticated task (job) protection and the task 
(job) priority structure should be simple. Job shuffling should be avoided. 
Purchasing memory for extra tasks (jobs) should be regarded as being a 
realistic solution. 

VAX/RT should be distributed, like RT-11, with the source code for the 
executive, ACP(s) and device drivers on the magnetic media. 

VAX/RT should be designed so that it is possible to implement some degree of 
multi-processing. The ultimate availability of peripheral processor boards to 
add extra VAX and/or PDP-11 CPU processors onto QBUS machines must not be 
overlooked. In particular this could provide the ultimate PDP-11 to VAX 
upgrade path i.e. run your RT-11 software under the control of VAX/RT on a 
peripheral processor board with access to RT-11 devices via the RT-11 ACP. 

**** VAX/RT ESSENTIAL FEATURES ON FIRST RELEASE **** 

Some of these features have been mentioned earlier, but are repeated 
here for completeness :- 

EXECUTIVE - RT-11 like user interface. ACP support. Paging support. Fully 
memory-resident. Multi-processing "hooks". High-speed vectored interrupt 
support. Virtual console (windowing ?) hooks, like TSX virtual lines. 

ANCILLARY CONTROL PROCESSORS - RT-11 file ACP (without any attempt to alter or 
extend the existing file structure). DECNET ACP supporting an end node. VMS 
(Files-11) ACP. Support for non file structured (fast ?) I/O ; direct to 
driver. 

DEVICE HANDLERS - Device handlers should be relatively simple (as in RT-11), 
although it is desirable that there should be proper support for internal 
queuing (particularly desirable with RQDX/KDA50 type devices, where many disks 
may be hung onto the same controller) and forking (via VAX interrupt request 
hardware). Support should be provided for all currently available DEC devices, 
including the RL02 (through any ACP since all use the same drivers), 

UTILITIES - Assembler. Linker. Librarian. Editor. Backup. SRCCOM. BINCOM. 

SIPP. (Or the VAX/RT equivalent of the last three RT-11 utilities). 

LANGUAGES - VAX/RT MACRO-32 (Obvious - you use it to write the operating 
system !). FORTRAN-77. PASCAL. 


VAX/RT should have the entire operating system executive in memory at all 
times. The executive should be as small and fast as possible, like RT-11, 
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*•** CONCLUSION •••• 

There is a final point. An inevitable reply to the VAX/RT proposal is 
to say that VMS does everything that is needed already. It is true that a 
substantial fraction of the functionality discussed above already exists 
within VMS. It is also true that there is an identifiable need for something 
| more suited to real-time and low-end systems. The VAX/RT proposal needs 

serious consideration. Can VMS possibly satisfy all the VAX market in software 
terms ? If so, why ULTRIX ? The PDP-11 has RT-11, RSX, RSTS, UNIX & MUMPS all 
supported by DEC. Obviously DEC would not be keen on supporting the same 
number of operating systems on the VAX. The support problems would be 
unmanageable in an economic way. However there is another aspect to this. 
Another vendor may develop a VAX/RT type of product. The reason another vendor 
has not developed a rival VMS type of product, and UNIX/ULTRIX is not a rival, 
is that it would have to be better than VMS to compete. The same is not true 
of the VAX/RT arena, there is no product from DEC. If DEC do not supply VAX/RT 
then another vendor will, this will not be to the advantage of the user 
community in the long term. A proliferation of "foreign" operating systems is 
1 to be avoided. The hardware manufacturer's support is vital. 
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APPENDIX - SUBMISSION FROM IAN HAMMOND 


VAX/RT and the rest of the world - the RT-11 architect ire 

RT-11 is an industry standard because it defines the baseline model for a PDP-11 
operating system and file-structure. RT-11 has been re implemented by DEC and 
others many times (RSTS, RSX, VMS) and is the basis of other systems (MPP etc.). 
The RT-11 file-structure is implemented by every serious DEC system. 

RT-11 has survived because it is an industry standard. VAX/RT should supply the 
same kind of baseline model for the VAX. 

1. VAX/RT should be able to be emulated on other VAX systems. 

Thus VAX/RT system services should be implemented so that they 
can co-exist in a VMS system. 

2. VAX/RT should support standard RT-11 disk volumes. 

RT-11 and real-time - the RT-11 implementation 

RT-11 supplies its architectire to a broad section of the computing community. 
However, the actual implementations of DEC RT-11 are solidly aimed at the real- 
time world (with layered products like CTS adapting it to other markets). VAX/RT 
must retain this implementations! grip on the real-time market. 

Each version of RT-11 has added additional overhead to RT-11’s response time. 
VAX/RT would have the opportunity to streamline. 

In the meetings I have attended the users who ’needed 1 VAX/RT were real-time 
users who wanted to collect large amounts of data very quickly. The size of 
address spaces has grown over the last decade - but systems have gotten slower, 
not faster. VAX/RT needs to deliver all the speed of the machine to real-time 
users. 


1. VAX/RT needs to be structixed like RT-11 with the equivalent of a 
very small, very fast SJ system. 

2. Paging needs to be optional (including stack extension). 

3. A fast file-system is required. 

4. Kemel-mocJe/System-space programs should be supported. 

5. Direct vectoring of interrupts to an application should be supported. 

6. Track/cylinder disk allocation should be supported. 

VAX/RT and GORT 

Good old RT is over ten years old. The PDP-11 could do with a new implementation 
of RT-11. If this ever happens the most useful model for the new system would be 
VAX/RT (if miracles strike twice in the same place)- 

1. VAX/RT should be designed with an eye on a culturally compatible 

PDP-11 implementation at some point in time. 
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RTT1A and RTT1B 

The 'Murphy report* suggests that VAX/RT support a new file-structure (RT11B), 
that RT11B be the bootable and primary file-structure. Other structures, includ¬ 
ing RT11A should be supported with loadable ACPs. 

Obviously VAX/RT supplies the right opportunity for a new file struct ire that 
can overcome some serious limitations of RT11A (for example the six character 
filename). But, VAX/RT should also support RT11A as a bootable and primary 
struct ire. 

1. It is going to take a long time for all the other systems to support 
RT11B. We already have enough compatibility problems without adding 
more. For example, consider a shop that wants to combine RTEM on one 
VAX with VAX/RT on dedicated machines. They will want to configure 
bootable disks. 

2. RT11A is smaller and simpler than RTI1B and therefore satisfies the 
minimal requirements of some dedicated systems more fully. 

3. Most sites will find that they have to have both RT11A and RT11B loaded 
for the first year or so. This costs them additional space. 

4- When will RT-11 support RT11B? Will RT-11 support an RT11B ACP or will 
it only be available via an exchange utility? 

VAX/RT is to RT-11 what VAX/VMS was to RSX-11. VAVVMS supports both F11A and 
FTIB as bootable devices and as the primary file-system, mainly because of the 
reasons given above. 

VAX/RT and an RT-11 AME 

VAX/VMS supplied an AME for its predecessor RSX-11 systems. Consideration of an 
RT-11 AME for VAX/RT should be made even if the newer models do not support com¬ 
patibility mode. 

1. Hooks should be available to support compatibility mode 
VAX/RT and networks 

Networks are the biggest computer futire. Networks are part of the system. RT- 
TTs support of DECnet represents one of its weakest areas. VAX/RT should be 
designed with efficient support for real networking. 

1. VAX/RT needs very strong network support 
VAX/RT and VAX/ELN 

At first glance VAX/ELN might seem to answer the needs of prospective VAX/RT 
users. It has better real-time facilities than VMS and does not hog memory or 
disk space. 

However, VAX/ELN does not remove the requirement for VMS. A VAX/VMS system is 
required for VAX/ELN program development. 

Further, PASCAL is the language of choice for a relatively small mmber of 
users. VAX/ELN is only sensible if you use PASCAL 

Finally, VAX/ELN does not supply the real-time parameters being requested. ELN 
puts the system between the hardware and the application. VAX/RT wants inter¬ 
rupts delivered directly to the application. 

The increasing sophistication of computer applications requires larger address 
'space* (an additional address bit each year). Real-time programmers need more 
than space to deliver new functionality - they need to be able to take direct 
advantage of faster CPU's. 
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General material for publication in the Pageswapper should be 
sent (US mail only -- no "express" services please) to: 

Larry Kilgallen, PAGESWAPPER Editor 
Box 81, MIT Station 
Cambridge, MA 02139-0901 
USA 

Preference is given to material submitted as machine-readable 
text (best is Runoff source). Line length should not exceed 64 
characters. Please do not submit program source, as that is 
better distributed on the VAX SIG tape. 

Change of address, reports of non-receipt, and other circulation 
correspondence should be sent to: 

DECUS U.S. Chapter 

Attention: Publications Department 
249 Northboro Road (BP02) 

Marlborough, MA 01752 
USA 

Only if discrepancies of the mailing system are reported can 
they be analyzed and corrected. 


Security Hole in VMS 4.2 

Art McClinton 
Mitre Corporation 
McLean, Va 

Every feature of an operating system that is designed to allow a 
user access to data that he would not otherwise have access to 
has the potential of leading to pitfalls for the system manager. 
Normally this would only come into play if you take over a 
system that was installed by someone else. It is very easy to 
install a few Access Control List (ACL) entries that can be used 
at a later date to perform extensive damage. The first thing a 
new system manager should do is analyze all ACL's in the system 
for potential side effects. 

Additionally, VMS 4.2 has a bug that allows non-privileged users 
to obtain SYSNAM privilege. The hole may be easily plugged by 
the system manager. The remainder of this brief article will 
describe the hole, its impact, and how to fix your system so 
that users cannot get in through the hole. 

Normally I would not write about security holes but this one is 
so widely publicized at this point that not to write about it 
would be the worse of the two evils. ACL's may be placed on 

files, devices or logical name tables. In the case of the 

logical name table, the system default is to allow any user the 
privilege of placing an ACL on any logical name table. This 
enables a non-privileged user the ability to set an ACL on the 
LNM$SYSTEM table to allow read+write+control. This enables the 
same user to modify entries in the table. This is fully 
equivalent to SYSNAM privilege. It does not take much 
imagination to write a trojan horse if you have SYSNAM 
privilege. The details will be left to the hacker. 

Like most security holes, it is very easy to close it once it 

has been discovered. The following code should be added to the 

system startup command file to close the hole: 

$SET ACL/OBJ=LOGICAL/ACL=(ID=[*,*],ACCESS=READ) LNM$SYSTEM_TABLE 

$SET ACL/OBJ = LOGICAL/ACL=(ID=[*,*] ,ACCESS = READ) LNM$SYSTEM_DIRECTORY 


Similar lines of code should be added for any other site 
specific system logical name tables that you have created. 

Digital is aware of the problem and plans to fix it in a future 
release of VMS. They have installed a tech tip at the Telephone 
Support Center. This information has also appeared on ARPANET. 
With such wide exposure, I feel that we need to communicate the 
problem and solution to as many system managers as possible so 
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that they may protect their systems. 


Editor’s Workfile 


by Larry Kilgallen, Pageswapper Editor 
Don't Forget to Vote - 

The System Improvement Request list is in the issue of two 
months ago, and the ballot is reprinted at the end of this 
issue. Photocopies of the form are quite acceptable; it is your 
membership number which validates the ballot as being yours. 

Isn't it nice - 

that a European DECUS member put in the effort to share their 
VAX Q & A with everyone who did not attend their symposium? 
Isn't it too bad it has been so long since anyone from the US 
has put in the effort to transcribe the similar sessions which 
are held at US Symposia? 
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A Concern about Security and DZ Ports 


by Jean Pollock and Jim Haskett 
Bloomington Academic Computing Services 
Indiana University 
Bloomington, IN 47405 


The Problem 


DZ11 terminal ports are polled for dial-up and hang-up events, 
as a result of which VMS connects users to or disconnects them 
from interactive terminal sessions. When this polling window is 
too large, a new user can slip into an existing session 
following a non-standard disconnect by a previous user. Such a 
disconnect can occur for users connected to a VAX via a terminal 
network. When the window is too small, there is a significant 
increase in CPU overhead. The width of this window is 
determined by a VMS operating system parameter called 
TTY_SCANDELTA. 

The polling interval is currently 1/20 sec. on our VAXs. VMS 
requires TTY_SCANDELTA to be larger than 1/100 sec. The default 
value is 1 second. 


The Benchmark 


An attempt was made to determine the optimal setting for the 
polling interval which would keep the CPU overhead and the 
security window at a minimum. To this end, benchmarks were run 
under VMS 3.7 (on Node Orange) and VMS 4.1 (on Node White). 
Both are VAX 11/780S. All unnecessary processes were terminated 
while the benchmarks were run. A benchmark program was written 
in non-standard FORTRAN to start an interrupt timer and then 
increment a counter until the timer expired. The value of the 
counter was recorded as an indicator of the amount of overhead 
lost to polling. Thus, smaller values of the counter are 
expected for frequent polling (i.e. smaller polling windows). 
Different values were assigned to TTY_SCANDELTA for each run. 
Generally, for each value of TTY_SCANDELTA, the program was run 
three times for one minute each. The largest variation in the 
results obtained for each parameter value was approximately 
0 . 1 %. 
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The Recommendation 


The results of these benchmarks follow. As a result of these 
benchmarks, we have recommended reducing the polling time from 
.05 sec. (i.e. TTY_SCANDELTA = 500,000) to 0.03 sec. 
(TTY_SCANDELTA = 300,000) on our machines. This will result in 
an increase in CPU overhead of approximately 0.6% 

We would like to thank Dave Schwab for his AST code and John 
Stockton for his help in executing the benchmark. 


The Results 


Polling 

TTY_SCANDELTA 

Counter Value 

Per Cent Change 

Interval 


Orange 

VMS 3.7 
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.01 

100,000 
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_ 
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Polling TTY_SCANDELTA Counter Value Per Cent Change 

Interval White in Counter Value 

VMS 4.1 
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TTY SCANDELTA Benchmark 
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A User’s Experience with Terminal Servers 


Stanley M. Rose 

Vice-President, Distributed Processing Technical Support 
Bankers Trust Company 
New York, New York 


The purpose of this article is to outline the 
experience of Bankers Trust with terminal server 
technology. This article is not intended to be a 
tutorial on Terminal Servers as many excellent 
articles have been written on that subject. 

After evaluating the DECSA, DECserver-100, and non-DEC 
units, the Bank chose the DECserver-100 and the 
decision has been substantiated by our subsequent 
experience. 


round 


Bankers Trust is a large user of DEC equipment. At present we 
have 18 PDP-11/70S (RSX11M-PLUS), and approximately 40 VAX 
systems, ranging from 3 MicroVAX-II to 7 VAX-8600. These 
systems have a terminal population of over 2500 terminals . 
Because of the criticality of the systems to our business most 
applications have a backup processor, which has, in turn, 
resulted in a good deal of terminal switching between primary 
and backup processors. In some cases there are secondary levels 
of backup, making the switching all the more complicated. 

The net result is that we had developed a very complex, and 
costly, investment in matrix switches, patch panels, etc. The 
complexity of the switching had become quite labor intensive as 
well. 

Compounding costs was the expense to install each point to point 
line. Due to the high costs of labor in New York it was not 
uncommon to have the costs of the line exceed the costs of the 
terminal, sometimes by a factor of two. 

To address these issues the Bank embraced the concept of 
Terminal Server based communications. After a detailed 
evaluation of several alternatives, which included installing 
and using foreign vendor equipment, as well as participating in 
Field Tests of the DECSA terminal server software and 
DECserver-100 products, the decision was made to use the DEC 
technologies. Subsequent work has further refined that decision 
to our usage of the DECserver product. 
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We felt that although, at times, other vendors might have had 
products that better handled certain niche situations, in the 
long run a better strategic decision was to use the DEC 
technology. We have found that the DEC products act as an 
extension of the system in a symbiotic relationship with VMS. 

Some of the advantages of the DEC products over the non-DEC 
units are: 

> No modifications to VMS, and no problems with lagging 
support for operating system upgrades. 

> Simple connection through standard DEUNA. 

> Easy installation of units. 

> Very easy network maintenance and configuration 
control. 

> Knowledge of VMS (now RSX), with the result that a 
server does automatic connection to the backup 
processor without the necessity of issuing any 
commands. 

> The software is centrally maintained on the VAX, rather 
than at each individual server. 


Some of the key features of both DEC units, that are now being 
used include: 

> Load balancing by automatic connection to least loaded 
processor. 

> Automatic connection to backup processor. 

> Preferred Service 

> Autoconnect 

> Multiple sessions 


Some specifics of each unit follow. 

DECSA 

The first server that we received was the DECSA (or PLUTO) box 
based Ethernet terminal server. This unit supports up to 32 
lines with modem control and reverse LAT. 
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Reverse LAT is the ability to use the server with a CPU that 
does not have native mode LAT support (such as from another 
vendor). Each port of the server is connected to individual 
asynchronous lines on the CPU. The terminal is connected to 
another port on the same or different server and can issue a 
connect to a group of ports which are assigned to a series of 
physical terminal server ports. Since we were only using the 
servers with VAX systems at the time, this was not a feature 
that we needed. 

For security reasons we have not installed dial-up access on the 
Ethernet, and therefore do not presently need the modem control 
feature either. 

Functionally, the DECSA supported all the features we needed, 
but was rather large for locating in a user area. The cost per 
port was higher than the cost on the DECserver-100, and since we 
did not need its added functionality we made the decision to 
standardize on the DECserver-100 instead. 

DECserver-100 


As with the DECSA, the DECserver-100 has satisfied virtually all 
of our functional requirements. Installation has been very easy 
and takes no more than a few moments to set up the 
characteristics. The multi-system access has significantly 
reduced the overhead and labor intensive activities involved in 
system switching. 

One design feature that we find appropriate for our use is the 8 
line size of the DECserver-100 . We have found this size to be 
a good trade off between economy of scale, system overhead, and 
minimization of single points of failure. 

The unit has been extremely reliable, and with close to 100 
installed units we have experienced no more than 2 or 3 
failures. Our maintenance strategy has been to purchase several 
spare units, and the minimum level of field service coverage. 
In the event of a failure, we simply swap in a spare unit and 
have field service replace the spare. 

Ethernet overhead is quite low, and with as many as 50 servers 
and 350 terminals on one cable, we have seen no perceptible 
impact on response time. 

The physical size and lack of special environmental requirements 
has made it easy to locate the DECserver-100 in office areas. 
Where we have had many units to co-locate, we have removed the 
outer plastic shell from around the inner metal case and shelf 
mounted them in standard ElA electronic racks along with DELNIs 
for concentration onto the Ethernet. 


The Field Test of the DECserver based line printer support has 
progressed very smoothly and has provided an additional 
functionality that will be used extensively. All-in-all, we 
have been very happy with the units. 

W ish List 

No one is ever completely satisfied with what is available 
give us a hand and we want an arm. There are several features 
we would like to see implemented in the future; some may be just 
software enhancements, while others will require new devices. 

The most important new software feature we need is host 
identification of the physical access port. This is a vital 

security feature to allow applications to be able to determine 

which physical terminal, at which server and port, is accessing 
the system. This has been the one feature we have lost in 
moving away from hard wired terminals. 

Another software feature we would like to have implemented is 

LAT support of multiple Ethernets to avoid a single cable 

failure affecting large numbers of terminals. We have developed 
a non-standard and, of course, unsupported patch to handle 
multiple LATs on several DEUNAs, but would like to have a 
supported method. 

A hardware feature that would complement the multiple Ethernet 
support would be a server that connected to two Ethernets, and 
did hot fail-over in the event of a cable failure. Note that we 
are addressing here the problems of cable failure, not server 
failure. 

Not actually a terminal server future, but one needed to support 
additional servers, is a high speed bridge between facilities. 
We have a need to locate the processors in one building, and the 
terminals in another - beyond the accessibility of fiber optic 
repeaters. As the number of devices increases, our need for 
more bandwidth grows with it. A device allowing us to connect 
remote Ethernets at T1 speeds is becoming more necessary. 

A capability that would off-load work from the central 
processors would be the implementation of the terminal driver in 
the server itself, especially on input. The READ QIO is 
actually a quite deterministic process, namely getting a set of 
characters until some condition is reached, and this could be 
moved out into the server. 

Once the terminal driver is implemented in the server, the 
various forms control packages, FMS and TDMS, should be 
implemented in the server as well. TDMS seems to lend itself 
quite well to this capability since it is full-screen oriented. 
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And, of course, we may find a use for reverse LAT and modem 
control and would like to have those implemented as well in the 
DECserver. 

Summary 

We have installed approximately 100 DECserver-100s in the last 
year and have been extremely happy with the unit. We are 
continuing to migrate terminals from point-to-point line 
interfaces to DECserver-100s and expect to double the number of 
installed units in the next year. 


European DECUS Question and Answer Session 


Transcribed by Tony Arnold 
VMS SIG Chairman, DECUS UK, Ireland and Middle East 
University of Manchester, Computer Graphics Unit 
Oxford Road, Manchester M13 9PL, England 

Transcript of VAX SIG Q and A session held at the DECUS European 
Symposium at Cannes, France. September 1985. 

Chairman 

Good evening ladies and gentleman. My name is Alan Silverman 
and I foolishly volunteered last year to the System Improvement 
Request in Europe. This time last year I stood up and asked why 
we had sent out 2,000 forms last year and only had 76 replies. 
I complained, and said I thought you could do better. Well I 
should have kept my mouth shut because this year we got 766 
replies and it took me a long time to count them! so, next year 
you will be asked to vote on the top 5, not the top 10. Okay. 
We did count all of them, and sent the top 5 to Digital. Andy 
Goldstein is here tonight to present the reply to the top 5. We 

will do them one at a time. The top one was number 30 on the 

list, which was split screen editing. This got 2402 votes 
including 53 first choices and was voted for by 370 people. 

Over to Andy. 

Andy 

I am pleased to report that we actually managed to get one 

right. Split screen editing is available in the new VMS editor 
VAX TPU and that is available in VMS 4.2 TPU is a completely 
programmable editor and it is intended to be used not so much as 
an editor by itself, because in fact it looks very much like a 
programming language rather than what you would view as an 
editor. Rather it is meant to form the basis of other editors. 
In fact, we already have several editors that are built on TPU 
and there are more coming. We provide 2 general purpose editing 
interfaces with TPU. There is an EDT emulator which is our way 
of eventually phasing out the existing EDT. We will provide the 
equivalent compatible EDT function through TPU. There is a new 
editor called EVE which was developed with extensive consulting 
with our human factors group and the EVE editor does support 
multiple window editing. It also supports arbitrary 
extensibility through TPU callouts and all kings of good stuff 
like that. EVE was designed specifically to be used in either a 
single editing or a multiple window editing environment. Any 
questions or comments? 
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Question from audience. 

Presumably this is all going to be supported on VT100S and 
VT200S and all that good stuff. How are you coping with the 
fact that the VT100 is not really all that good at split screens 
and scrolling when you have got them mapped together? 

Andy 

Okay, well I haven't been directly involved with EVE, but 
basically, the VT100 does support split screen scrolling regions 
and about the best you can do is swap them around and just set 
up the area that you want to scroll for scrolling. I haven't 
actually used it myself, so I can't comment personally on the 
performance. 

Chairman 

The second most popular item was number 50, which was one that 
we have seen before, and that is on line disc compression. 

Andy 

SIR number 50 relates to on line disc compression and observes 
that the increasing use of Winchester discs, in particular 
single disc systems makes it increasingly impractical to 
reorganise your storage space with Backup, and of course that is 
also a problem in that you have to take down your system or at 
least your application to do that, and also as the discs get 
larger, again using tape as the intermediary storage becomes 
less practical because of the tape volume and simply because of 
the length of time it takes. So the request is for a utility 
that allows disc compression and free block consolidation and 
preferably on line as concurrently as possible with system 
activity. We agree that's a fine idea. We obviously haven't 
done it yet! This is a relatively new SIR request. This has 
not come up in past United States SIR ballots. We certainly 
intend to take a good hard look at this problem. I have some 
experience with it. I actually worked for RSX back in the old 
days when we had a gadget called DCU which some of you may 
remember- I think DCU was a very good demonstration to us all 
that this is not an easy problem. One of the interesting 
problems other than simply interpreting the file structure 
correctly is coordinating the compression with ongoing file 
activity, and of course clusters add a unique twist to that. 
Also the performance problem is quite difficult because inplace 
disc compression is to the best of my understanding an 
inherently n squared problem and so with some very large discs 
you run into some very serious performance problems. Obviously 
you can do intelligent things to make it run faster and we are 
going to have to spend some considerable time and attention in 
getting reasonable performance out of it. Any comments or 
questions? 


Chairman 

The next one was a request for the log out of inactive 

terminals. 

Andy 

The reason I got to do this session, by the way, was because I 
guess I ended up writing 4 out of 6 of the SIR responses. This 
has been a feature that has been requested for a long time. We 
have been thinking about it. One of the reasons we have not 
done it is because it is not quite as easy as it looks. At the 
same time it hasn't bubbled up as high on the priority list 
because it is the kind of thing that can be supplied by the 
installation. It is simple to build an extra watcher process 
that performs this function. Obviously we understand that you 
would rather see something like this provided by DEC and be 

general enough to handle everyones problems but that is exactly 
where the rub lies. The difficulty is coming up with a correct 
decision that a terminal is actually inactive. You might start 
out by saying that if there are no IOs over a certain period of 
time then that terminal is inactive, then you raise the 
question, what if there is some kind of long running job on the 
terminal in question? you can follow these through several 

levels. You can argue that maybe there is a server process 

connected to the terminal and in fact all of the active 

computation is being done in sub processes and you can dig 

yourself as deep as you like. I think one of the thing that we 

are looking for in terms of guidance, is what level of 

intelligence people feel is really necessary in such a facility, 
and I am certainly willing to entertain suggestions from the 
floor. 

Long silence. 

This is going to be a very boring session unless people get up 
and start saying something! What more can I say about this 
capability except we have had it in mind and as soon as we get 
out of the way what we consider some of the more pressing 

security features, we are going to look at it. It has appeared 

on the bottom end of some of our project plans in the past and 
so far it has always ended up below the cut off line. The fact 
that it has been specifically requested by a couple of SIR 
ballots should influence our decision on that. 

G. S. Bal, University of Liverpool VMS 4.1 

We have the problem that the architecture of VMS does not have 
any timeout feature built into it. We have a network controlled 
by Gandalf PACX and the contention device. At times it is 
possible to switch the controller off or the terminal off. That 
switches the terminal port off on the contention device and 

leaves the whole port in. Anybody who comes in next gets into 
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somebody else's session. 

Andy 

I would answer that by suggesting that the terminal lines that 
you have connected to the terminal switch are incorrectly 
configured in that you do not have modem control enabled. When 
a line has modem control enabled and goes into any kind of 
terminal switching state, VMS should treat that as a modem hang 
up and either log out the job or disconnect the process 
depending upon whether you have disconnectable terminals enabled 
or not. If we leave processes floating that someone else can 
accidentally reconnect to that is the result of the modem 
signals not being correctly handled. 

D. Bal 

This system did work on 3.7? 

Andy 

This is true on 3.7. Obviously 3.7 did not have disconnectable 
terminals but a properly configured terminal set up in 3.7 
should disconnect the lines to the best of my knowledge. 

D. Bal 

DMF 32 interfaces have got modem signals on both 0 and 1 not on 
the 6 lines on the same board. How do I put the modem signals 
on those 6 lines? 

Andy 

The DMF supports modem control on port 0 and 1 only. If you use 
the other ports on a switched connection you are running at your 
own risk. 

D. Bal 

The risk is that this is an undergraduate teaching service. You 
know the challenge of the undergraduates to explore the system 
and wreck it if they can possibly do it, and it hampers our 
resources time and time again to sort the things out. Hence the 
requirement. 

Chairman 

The next one is batch checkpointing with 785 votes. 

Andy 


This SIR is a request to be able to stop and resume long running 
batch jobs in case the system needs to be shut down for whatever 
purpose and the considerations are obvious. When you have a 
batch job that runs for a number of hours or a number of days, 
perhaps even weeks, you cannot afford to lose that investment in 
time on that particular job if the system either crashes 
unexpectedly or needs to be shut down for any reason. 

We have been hearing about the desire for this ever since we 
announced the future existence of the VMS checkpointing facility 
which I think must be close to two years ago now. That's part 
of the data integrity features that we are working on for future 
VMS releases. We have had the checkpointing facility, that is 
what we have implemented on VMS, pretty wel ready to go for a 
while and it was a casualty of the deferment of the journaling 
facility. It turns out that checkpointing makes use of recovery 
units which in turn makes use of journals and as a result of 
that set of dependancies we have not been able to ship 
checkpointing yet. We do intend to ship checkpointing some time 
in the near future and it will be followed shortly thereafter by 
the checkpointing facility. 

Now I need to point out that the checkpointing facility that we 
intend to provide is not going to be as fully general as people 
would like. The reason is that saving and restoring the state 
of a job is a very difficult problem and the more transparent 
you try to be about it the more difficult it gets. We started 
with the level of dealing with assigned channels and open files 
and the address spece and things like that, that we felt were 
doable. However, when you get to the level of saving the 
complete DCL context when you have a job that has IOs that might 
be currently in progress and other side effects of that sort, 
things start to become extremely difficult and we found it 
necessary to defer that set of problems to another time. 

So there are a number of restrictions that will be in effect on 
the initial checkpointing capacity. The job must declare 
checkpoints by itself, you cannot from an operator terminal 
enter a command that causes the job to be checkpointed, the job 
must be checkpointed itself. It must request the checkpoint 
voluntarily. Secondly the job cannot run in the full DCL 
environment; it must be run as a separate process by itself. It 
is obviously not the best that people would like but it is the 
best that we felt we were able to build at this point and we are 
going to continue to look at this. Comments or questions? 

Chairman 

The last of our top five was the request for disc quotas by 
groups. 
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Andy 

This SIR requests that quotas be allocatable by groups of users, 
that is, by the group field of UIC as well as by the individual 
UIC. The primary rationale of this appears to be that people 
want to allow disc space to be charged to, say, a project as a 
whole rather than to the individual members of that project, 
since presumably the file space in question is owned by the 
project at large rather than by the individual people. Now in 
V4 we have provided the identifier mechanism that allows the 
assignment of arbitrary project groups and arbitrary project 
membership, membership in multiple projects by one person and 
related features. One of the features that goes along with that 
mechanism is the ability to charge disc space to a project 
identifier. This means that you can assign an identifier to a 
person with resource priviledge and that allows that person to 
create files owned by that project identifier. To make use of 
that, then, what you would do is set up a project library 
directory where the directory file is owned by the project 
identifier. Access control lists make that directory and the 
files in it accessible to the project members and the file 
ownership defaulting rules in the file system will cause files 
that are created in that project directory to be owned by the 
project identifier, provided that the person creating the file 
holds the project identifier with the resource priviledge. I 
guess my question to you is: Did we do it right? Is this what 
you wanted? 

Questioner (no name). 

We are using this feature with partial satisfaction. It is fine 
as far as it goes, but if you have somebody using one of these 
identifiers with resource attribute, each individual user still 
needs a disc quota of their own. It is required by some of the 
utilities like the sort merge and certain Dataretrieve 
functions. So irrespective of the fact that you can have this 
group accounting, each individual still requires their own disc 
quota. 

Andy 

That's correct for things like temporary files, files that in 
effect belong to the individual user. So you are suggesting 
that you would also like just for simplicity of authorisation, 
to hand out the quota to the group rather than to the individual 
persons. Thank you, we'll take that back. 

New questioner. 

Yes, we made use of this to try and set up a project account. 
It had several side effects with some of which it didn't 
actually work. In the book, I can't remember which guide it 
was, it sets up the file ownership with the file ACL with "no 


propagate" so if you then edit your file it doesn't propagate 
the access control list and you lose touch with it. 

Andy 

Let me just explain for those of you who are not quite so 
familiar with the mechanism. In a circumstance like this, where 
the file system creates a file whose ownership is not the UIC of 
the person creating it, the file system automatically adds an 
access control list entry to the file that gives the creator 
access to the file. That is based on the principle that you 
really ought to have access to what you just created. That 
access control list entry is marked with a no propagate 
attribute so that it is not propagated to future versions of the 
file. I believe that is actually the right way because every 
time a new version of that file is created the access control 

list entry that grants access to the creator will in fact be 

added to it. What that means is that for the general project 
accessibility to the file you have to make sure that the file's 
access control list otherwise grants access to the project but 
if we did not mark the ACEs no propagate, what would happen is 
that as different individuals created different versions of that 
file, the ACEs would pile up. Every time somebody created a new 
version, we would pile up a new access control list entry that 
granted access to that new person and we felt that was just 
incorrect behaviour. So rather you get full access to the 

particular file instance that you created and you rely on the 
project access controls for the general access for the project. 

Questioner 

So you are actually saying that you can't edit the file. It 

means the user that created that file can't successfully edit 
that file. 

Andy 

No, that should not be. 

Questioner 

As he edits that file he creates the higher version of course. 
And it is that higher version that does not propagate the ACL. 

Andy 

That's right. It does not propagate the access control list 
entry that we put on it. Rather, it gets a new one, which is 
appropriate to the person that has created that new version. 

Questioner 
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| Then maybe there is a bug hanging around in 4.1 because it 

{ certainly does not progogate anything. It has the project 

j identifier on the ACL but not the owner. 

Andy 

Okay, yes, something is wrong. There are some other wrinkles. 
If you are running with something like sysprv then also we don’t 
put it on. The rules are somewhat complicated but they are 
complicated to work right in the greatest number of cases. 

New questioner 

I have installed this facility, too, and I have had a lot of 

: problems. You have to be very careful if you edit this feature 

for files or directories which no longer exist, because if the 
users are allowed to edit under this new identifier, they have 
the files and if they first change the owner, they can do 
nothing with the file. So they first have to add the ACEs and 
then have to set the owner and if they don’t do it this way they 
always come to me as system manager and say, "please give me 
access to my file". The other difficulty we had: the normal 

user who is allowed to access disc space via such an identifier 
cannot see the used disc quota of the identifier. So if the 
quota command says "no privilege" for a certain operation, the 
only way is to give all users access to quota so every user can 
see this quota for every other user. 

Andy 

That is an oversight which we should fix. 

New questioner 

I was going to ask the same point because I have found the same 
problem: you cannot find out the quota. But in addition, the 
previous comment about the propagating ownership. When the file 
is edited by different users with a version limit on the disc, 
say version limit of 5, when the sixth edit is done you can't 
get out of the edit because you can't delete the sixth file. 

Andy 

Okay yes, because you don't have permission to delete the file 
and .. I guess my answer to that is that the project access 
s then should be giving you permission to delete the file. It 

e simply means that you have to set up your project access control 

f lists correctly for that to work. 

New questioner 
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Is there any way of stopping that behaviour of the new access 
control list? Is there any way of preventing the access control 
list entry being added on creation of the file. Because it also 
gives control to the creator. We have applications where we 
would like a user to be able to create data files but not be 
able to delete them or change any attributes of the file. Is 
there any way of stopping them doing this? 

Andy 

At present, no, there isn't. We will have to take that back as 
a suggestion. I would suggest that if you want protection 
behaviour different from the default that you make use of the 
VMS services to make the file protection what you want it to be. 
There are any number of services available to you so that you 
can set the protection to what you feel is right and override 
whatever the file system does. 

Questioner 

It's a long way round, though, isn't it. 

Chairman 
Thank you 
Alan 

To all those of you who sent in responses to the SIRs, thank you 
very much. If you have ideas for new SIRs please send them to 
your chairman or to Peter, and we will try and do the same thing 
next year. I will send for publication the top 5 of the replies 
and list all of the votes to the Pageswapper so you should see 
that in a few months time. Thank you. Over to Peter. 

Peter 

Before you go Alan, we would like to thank you very much for 
your hard work. Now. The busy part of the evening. I am going 
to call out the names of the questioners. 

Christiane Letertre, CERN. VAX VMS 4.1 

We have a problem with quorum disk in a cluster. Each time the 
system was rebooted we got the disc improperly dismounted. Is 
that normal or did we do something wrong? 

Peter 

This is something which a number of us have had. I get it with 
RM05s. I think it must be normal. 
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Andy I would like to add that it has nothing to do with clusters 

because we had the same thing on a perfectly normal RM03. 

Do you have any kind of error messages that might indicate that 

the rebuild on the disc in question is failing? New questioner 


Christiane 

We do not. Apparently the disc is good. 

Andy 

Obviously the disc will get rebuilt and will require rebuild any 
time a node crashes in the cluster. Are you also seeing this 
when you reboot after a perfectly normal shutdown? 

Christiane 

When we reboot after a normal shutdown. 

Andy 

And you are running 4.1. It does not sound completely normal. 
I can't really say very much more about. It does sound as if 
something is out of phase in the volume storage control block. 
That is where we track the information about whether the volume 
needs to be rebuilt or not. We do that by keeping track of the 
count of the number of nodes that currently have the volume 
mounted and that is supposed to be reset by the rebuild 
function. If the rebuild function is not properly resetting 
that value then the volume will rebuild every time you mount it. 
About the best I can say is that we will have to take that back 
to see if we can identify any problems. 

Mr Dramer 

We have had the same problem, but we made a backup and cleaned 
the disc. We put 5 backed discs with BACKUP/IMAGE and we have 
not had any problems up to now. 

Andy 

That certainly suggests to me that there is something in the 
storage control block that is not properly being cleaned out by 
the rebuild. When you copy the disc with Backup the storage 
control block does get completely rebuilt, and so I guess I 
would suggest taking that approach and seeing if that clears the 
problem. That also gives us some additional information as to 
what might be wrong. 

Questioner 


Could I say that in the 4.2 documentation it indicates that at 
least some instances of this have been corrected. 

New questioner 

As a note I have found that if your quorum disc is not your 
system disc a normal system shutdown does not dismount it. That 
could be the cause of the problem. 

Andy 

Ordinarily simply marking the disc for dismount should be 
sufficient to clear the bits in the storage control block but 
again I think we will have to look at it. 

No 2 

What could be recommended in between the time between now and 
the eventual standard utility that could become available to 
reorganise discs without backup-restore actions. 

Peter 

At present what we recommend is shutting down the use of that 
disc and doing an image backup, meaning either a disc to disc 
image copy or if you don't have a second disc to do an image 
save to tape and then stand-alone backup image restore from the 
tape back onto the disc. 

Questioner 

And if you want to provide a 24 hour service? 

Peter 

I have to admit that is not possible and we don't have the 
ability to do that at present. 

No. 3 Anders Lyngarth, TSL data, Sweden. MONITOR, SHOW DEBUG. 
VMS 4.1 

I have a question about how to implement foreign terminals on 
the VAX VMS 4.1. I have tried it by way of using the module in 
sys examples called SCRFT.MAR which is the same module as the 
VMS 3.x. The module doesn't work as is stated. Where could one 
find information on implementing foreign terminals, if SCRFT.MAR 
is obsolete? Or is there an error in SCRSHR? It could be said, 
too, that the SMG$ routines don't work as the documentation 
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suggests in defined foreign terminals. 

Peter 

The old SCRFT was always an undocumented unsupported interface 
and although in V4 there is an attempt to make it upward 
compatible I have heard at least a couple of reports that it is 
not 100% upward compatible. We do recommend that with V4 you 
use the SMG foreign terminal package. 

Anders 

I do that, but DEBUG doesn't use the SMG. 

Peter. 

Correct. It is going to take VMS a while to get its utilities 
using SMG. It will take us a while. We have had that 
requirement from US DEC users as well. You mention here that 
there are problems with the documentation. We are aware of 
several of those problems and there are a couple of bugs in 4.0 
and possibly 4.1 that are being cleaned up in 4.2. 

* 

Anders 

May I mention one thing. If you have another terminal with the 
line drawing character sets consisting of two characters you 
define the line drawing characters in the SMG document as 
strings which only yields the first character and that is not a 

string. What have you changed between V3 and V4 in the SCR 

interface? 

Peter. 

In the SCRFT? The old screen package, the SCR entry points 

still exist in V4 but the code that is behind them is completely 

different. Although the intent was that they be replacement 
routines, it was a total rewrite from MACRO to BLISS so things 
like counting on R6 having the right data structure pointing to 

it and things like that which people did do is not true when it 

was rewritten in BLISS and that was what gave most people 

problems. There was a data structure which was around most of 

the time which was what people used. 

Anders 

Okay, so I will close the openings for foreign terminals to work 
as display terminals on VAX for the moment. Until you come up 
with the utilities.. 

Peter 
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Correct. 

Anders 

Do you know how long this will take? 

Peter 

No, it probably won't happen at the same time, we will probably 
move our applications to SMG as time allows. One thing that has 
been suggested is that an ambitious customer could replace 
SCRSHR with a SCRSHR which called SMG and via that route you 
could get things that called SCR really calling SMG then you 
would get the foreign terminal support. 

Another voice 

I believe DEBUG for 4.2 is now using SMG. You could talk to the 
people downstairs at the software house tomorrow morning to make 
that sure but I believe DEBUG for 4.2 has been converted. 

Anders 

I thought it a little bit funny because you said it was totally 
new but it didn't use SMG. Wasn't the DEBUG totally rewritten 
for V4. 

Answer 

Yes it was, but it was considerably rewritten before the SMG 
package existed. It was a timing problem. 

No 5 Harneit Jeus 

How can I have an SYLOGIN that is effective for users that log 
in both under the DCL CLI and MCR? If I am using a system wide 
log in procedure I cannot write it only for DCL. 

Andy 

What we normally recommend is that you define SYS$SYLOGIN to 
point to SYS$MANAGER:SYLOGIN and leave off the file type. What 
will then happen is the CLI will supply its own default file 
type for opening the command file, DCL will use .COM and MCR 
will use .CMD, and that you allows you to have separate login 
files for each one, and then you can either make them 
functionally the same, one in DCL, one in MCR, or you might have 
completely different ones, even an empty case if you didn't want 
it. 

No 7. A Marriott. Contraves Ag. Zurich 
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How may a program at run time define a process permanent message 
file to supplement the existing system messages? That is to 
achieve the equivalent of the DCL "set message" command. 

TAPE ENDED HERE - ANSWER NOT ON THE TAPE. 

No. 8 Cino Crepaldi, Germany 

Under RSX there is a command $SET TERM/SLAVE. We have a couple 
of Perifold devices connected via terminal to VMS and we would 
like to break that protocol between username and user 
authorisation failure when you reboot the system. And you added 
index file support to DCL, however how can I delete a record in 
these index files? 

Peter 

The answer to the first problem is SET TERMINAL/NOTYPEAHEAD, one 
of the more intuitive DCL commands. The action of turning off 
typeahead disables the login. The second question was how can I 
delete an ISAM record from DCL. I don't remember the syntax. 
There is a way to do it. It may be something like a qualifier 
on the read command or something like, 

.comment from audience.. 

Peter 

It is WRITE/DELETE. I know it is there because we use it on 
some of our own DCL hacks and so it is a matter of perusing the 
manuals. The READ and WRITE commands are the only ones that DCL 
operates on at that level so it has got to be a qualifier to one 
of those two. 

No. 9 Drozak, Belgium. VMS 4.1 

When you use the shut down command it asks you if you want to 
spin down the discs. If I answer yes to the question all my 
discs spin down except the system disc. 

Peter 

We can't spin down the system disc. The problem is a kind of 
"you can't get there from here" situation. The problem is that 
the system disc remains in use until very, very late in the shut 
down process. The very last phase of the shut down process 
involves making sure that all of the modified pages on the 
modified page list are flushed back to the backing files on the 
disc. This is particularly important when you have had user 
processes that have had files open as global sections or 
whatever. Obviously you want to make sure that the global 
sections are properly written back to the files. That is done 
in the very last phase of shut down by the OPCRASH utility 


program. 

Immediately after that OPCRASH does a bug check. We write out 
the system dump file and again you might argue that it is not 
necessary to write out a system dump file for an operator 
shutdown. On the other hand there is one piece of information 
that must be written out which is done using that mechanism and 
those are the error log buffers. Once we are into bug check we 
no longer have the regular system disc driver available. In 
fact, the bug check is even written out using the boot driver, 
which is what we booted the system with and the boot driver does 
not have the capability to spin down the disc, so - to make a 
long story short - by the time it is possible to spin down the 
system disc, we no longer have the ability to do so. 

Drozak 

Well can anybody help? Because I must stop my machine when 
there is nobody in the room and I am afraid to stop the power on 
the machine when the system disc is still running. 

No 10 (no name) 

One of my users used EDT to edit a directory file and EDT got 
confused and the directory got corrupted so I have a directory 
file that I cannot delete. 

Peter 

Despite the documentation, this is the purpose of the SET 
FILE/NODIRECTORY command. This command was specifically put in 
place to allow you to delete a corrupted directory and you issue 
that command naming the bad directory file. That clears the bit 
in the file header that identifies that file as a directory. 
Subsequently you can delete it and then reclaim the files under 
the directory with ANALYZE/DISC. The documentation for SET 
FILE/NODIRECTORY has been fixed in 4.2. 

No 13 W P Ingenegeren. Utrecht. VAX/VMS 4.0 

This has happened to me today, I demonstrated it. Some people 
are told they have new mail when they log on but there is no 
mail. It looked almost as though it was counting pages and 
decrementing files. I have been receiving these questions, 
mainly SIRs, from the VAX info file and I have been getting... 
when I finally finished I think I had six more mail messages but 
no mail. 

Andy 

I can't point to the specific event that might have caused this 
problem. This problem can result because the new mail count is 
not stored in the mail file. In VMS V3 it was stored as a field 
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in the authorisation record. In VMS V4 there is a separate file 
called VMSMAIL.DAT in SYS$SYSTEM which is MAIL'S general purpose 
database file. The new mail counts for all of the users are 
stored in that file. Obviously if that file gets out of sync, 
somehow with an individual's mail file (which might happen, for 
example, if somebody changes system discs or boots the system 
off a different system root at some point) then the mail count 
will get out of phase. The way that you reset the mail count is 
to do a READ/NEW when there are no new messages and that will 
force the mail count back to zero and get it back in phase. 

NO 12 Mats Jansson, Sweden 

I have tried to make possible to print out in both 6 and 8 lines 
per inch through DEFINE/FORM with set up file that does the 
necessary things with the printer. I have found that it was not 
possible to define the reset module to be printed out at the end 
of the printing at the form. It was necessary to do this at the 
queue. I think it is not what you always want, a blank page at 
the end of every file printed. I want to have a switch on the 
DEFINE/FORM to make it possible to just after this file with 
this form to reset the printer. Is this planned or must I reset 
after every file in the future? 

Peter 

You are sending a setup module? 

Mats 

Yes. On V4.1. 

Peter 

And what is the content of this setup module? Is there an 
escape sequence in here? 

Mats 

Yes, defining a number of lines on the printer. 

Peter 

Is there any text in that set up module? 

Mats 

No. 

Peter 


Just an escape sequence? 

Mats 

Yes. 

Peter 

I believe this problem is fixed in 4.2. We have a problem in 
which the symbiont should recognize the fact that it is 
receiving strictly a setup sequence and there is no text to be 
displayed on the paper and it is still saying, "I have received 
more than zero characters therefore I need to issue a form feed 
to get to the top of the form". 

No. 13 Sally Antill, Vickers Design. U.K. VMS 4.0 

Do DEC really believe that it is acceptable to remove commands 
and system services in a new version? And to change commands 
such that command files, etc., uddenly give errors? 

Andy 

I would like to see a more documented example of what the 
problem is. 

Voice 

She mentioned this in her session. One of the examples was in 
the MAIL utility where the EXTRACT command replaced the FILE 
command. She used the FILE to extract mail now it is EXTRACT to 
file. 

Andy 

Yes, we changed the command in mail. Certainly in DCL in system 
services I believe we have been as careful as we can possibly be 
to preserve compatibility between releases. 

Comment 

With the exception of the INITIALIZE/QUEUE command where you 
change the /PRIORITY to a /BASE_PRIORITY. It makes no sense. 

Andy 

The fellow who did that is no longer with us... (LAUGHTER) 

Peter 

With regard to /PRIORITY and /BASE_PRIORITY I think the 
rationale for making that change was that in V3 the /PRIORITY 
qualifier was used to mean two distinct things: the relative 
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schedule and priority of a job within a queue and also the 

execution priority of that job. We got a lot of SPRs and 
questions at DECUS sessions where people were getting that 

concept confused, and I think that was one of the motivations 
for making that change. I can't read the guy's mind.. 

Andy 

Every once in a while we do make a change in behaviour. MAIL 

for example: I use the excuse that we really were presenting a 

significantly different MAIL version than we had in V3. You can 
either accept that or not as an excuse. In other circumstances, 
we have made some changes and they have often been by 
substantial popular request. One of the ones that I recall was 
changing the default setting of /REWIND in Backup. I think from 
the general level of feedback that we got, I believe that the 
change was right. The level of complaints when we made the 
change was actually relatively low. I was pleasantly surprised. 

Comment 

May I give a comment on the MAIL thing we just discussed? In V3 
VMS when you use the FILE command you create a text file which 
is in fact a mail file with a form feed at the beginning. So if 
you wish to print it you just print it. But if you use the file 
command with the same name it in fact creates a folder and a lot 
of people using V3 do not know this. So if you type "FILE", 
then message 1, 2 and 3 with the same file name, you will notice 
you don't have the message file created because all these 
messages are added one after the other and in fact the file 
command creates a folder. With V4 VMS it also creates a folder. 

Andy 

Frankly my comment is that I wish the person who implemented the 
MAIL facility were here to speak for it. Bill tells me that he 
(Ben Schreiber) will be here tomorrow morning. 

Comment 

All the layered product people - they had a Q&A already today 
if questions come up during the VMS Q&A for the layered product 
people, of which Ben Schreiber is now one, they can be directed 
tomorrow on the demo floor. 

No 14 Qar 357 

Since we run a fairly open shop (being a large international 
scientific lab), we decided not to implement password lifetimes, 
so these are set to zero in the UAF. Recently, however, a 
neighbouring system had a malicious break-in on an account where 
username=password. So we decided to issue all future accounts 
with pre-expired passwords. We found that indeed all new 


accounts were marked as pre-expired but VMS did not care. No 
warning message on login, no requirement to change the password, 
nothing. Only when we made PWDLIFE non zero (we chose 3650 
days) did pre-expiry do what the documentation says it should 
do. Either this is a bug or the documentation should be changed 
to point out that the pre-expiry flag depends on finding a 
non-zero PWDLIFE. 

Andy 

That is a cute little wrinkle that had not occurred to us and we 
will take it back. 

NO. L5 Eva Larsson, University of Stockholm VMS 4.1 

The problem I seem to have with my VAX 785 might be very site 
specific but may be interesting if someone here has come across 
it before. As I said I have a 785 which is equipped with one 

Unibus, 8 DZ11 and 96 Emulex DMF32• This worked fine under V3.7 

but now on V4.1 there seems to be a problem with hanging. If 
there are more than 35 users on the system, eventually the 
processes will hang one after the other until the entire system 
is hung. You can't get through the Emulexes, nor even the 
console. The only way to manage this is with control-P and 
rebooting the system. This is very irritating as it happens 

something like 3 times a day. I have heard at a computer 

conference system that there is a machine in Germany and another 
in U.S. which seem to have the same problem. At least they 
have similar symptoms. 

Peter 

I think every system in the U.S. that had either Emulex or Able 
ports started hanging when V4 came out. In V4 we enabled a 
feature that DMF had but we had never turned on in V3 called 
auto xon/xoff which allows the hardware to do the xon handling. 
DMF apparently had had the bugs fixed by the time we got to use 
it, and Emulex and Able had never had that feature turned on and 
hangs occur with that situation. It is my understanding that 
both of the companies have been very good about giving out new 
microcode to people who had those boards and you should probably 
contact your company. Another work-around that we don't have a 
whole lot of faith in, but seems to work (we don't have Emulex 
boards, that is why I seem to hesitate), is there is a special 
SYSGEN parameter, TTYDEFPORT, not DEFPROT which is default 
protection but DEFPORT which is a port control word. If you set 
the low bit of that... 

Eva 

We were aware of this before installing V4.1 so that is not a 
problem. 
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Peter 

You still get hangs. I guess take a crash and send us dump. 

Eva 

I have spoken to the entire system department in DEC Stockholm 
and they seem just as puzzled as I am. The problem is new even 
to you? 

Andy 

In the problem description you said you find a long XQP queue, 
meaning which queue? Are you talking about a request queue 
inside a particular process? 

Eva 

Yes. I am not very good at VMS internals but if you look at the 
system dump analyser at the crash dump you can see that the 
request 10 queue is empty and the request XQP queue is normally 
empty as well but when you force the crash you get quite an 
amount of requests queued up in the XQP queue. 

Andy 

When I read the problem description I started thinking of 
something altogether different. We have noticed that a good way 
to get the entire system bottled up is to have the disc driver 
subsist and lose an 10 on you. When this happens, chances are 
very good that it is a file system 10. What happens then is 
that the process who is executing the file function that is 
responsible for that 10 obviously hangs in the middle of 
whatever they are doing. They are presumably holding some set 
of file system synchronisation locks. Any other process which 
subsequently comes through a similar path in the file system 
will then get hung behind that lock and, for example, if that is 
the volume allocation lock you are guaranteed to bottle up the 
system fairly rapidly. Now the way you would backtrace that is 
to look at all of the processes making no progress. Do a SHOW 
PROCESS/LOCK on a couple of those to identify what they are 
waiting for. The file system locks are all identified by a 
resource name beginning with F11B. Take one of those locks, do 
a SHOW RES0URCE/L0CK=, giving the lock id. That will tell you 
who is holding the lock. Then you go to the process who is 
holding the lock, again do a SHOW PROCESS/LOCK on that, to 
establish what that process is waiting for. You may have to 
trace through several levels of locking dependencies. 
Ultimately you will find a process who has no lock dependencies 
who is waiting for some other reasons. One of the things to 
look for here is a busy 10 channel. See if there is an 10 
outstanding, then look at the device to which the busy channel 
points and see if you can find either the stray or stopped 10 


packet. If you want to go to that level of chasing, that is 
what you can do. Alternatively if there is a stray 
undiagnosable hang, it should come to us with an SPR. 

Peter 

When your system is in this state do your terminals echo control 
0, output on, output off? Does that work? 

Eva 

No they don *t. 

Peter 

That happens at driver IPL. Sounds like hardware to me, sounds 
like it is the Unibus. If the system is hung in the way that 
Andy is describing it is going to be looping at a lower IPL and 
the terminals will be able to do output on, output off. If they 
can't do that your system is sick. 

Comment 

I have had the same situation. I switched off the Unibus and it 
didn't help anything. I have Emulex only on one Unibus and I 
switched it off. Bill Travers told me it would help but it 

didn't. It must be something different. 

Comment 

We also have this beast called Camak. It causes us many 
problems. This is a SYSGEN configuration map of the Unibus of 
an 8600 with Camak on it and DMZ lines. What we don't 
understand is that at TXB it jumps up from vector 320 to 450. 
Then it carries on up to 600 where it overflows onto the Camak 
and gives us a hardware problem. What I would like to know is: 
How does autoconfigure work and could anyone explain why it 

suddenly jumps from 320 to 450? 

Peter 

Your question is: Why do the interrupt vectors go from 320 to 

450. Well you got me. I don't know (much laughter). I wrote 

the code (more laughter). If you configure your system like 
that, does it ever configure? 

Questioner 

This is autoconfigure. 

Peter 
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Is that a show configuration or is that the result of...? 
Questioner 

That's AUTOCONFIGURE ALL. I looked at the drivers manual and 
there were some very strange devices which had very peculiar 

names with vectors in that area so I did exclude these devices 

and it made no difference. Where can I look? Do you test the 
vectors? 

Peter 

Everybody in VMS is on SYSGEN some time or another. We test 
CSRs. Vectors just kind of follow along merrily. The computing 

of the interrupt vectors is really quite simple. It's just is 

there a device here...no... 

Questioner 

That could be a clue because this Camak thing has a large number 
of CSRs. 

Peter 

That's the little CAA device down at the bottom. 

Get rid of it! (much laughter) 

There are a couple of things you can do when you are debugging 
these configurations. There is a SHOW/UNIBUS command. Do it on 
hard copy because it is going to generate a lot of output. It 
gives a complete map of what AUTOCONFIGURE sees and how it makes 
its decisions. Also when you do AUTOCONFIGURE, you can do 
AUTOCONFIGURE/LOG and if you see any strange devices pop up..5 
line printers, its devices found that if it doesn't find a 
driver, if it is not a supported driver it doesn't complain. 

Questioner 

We actually figured that out and we do see 5 line printers so we 
exclude line printer. 

Peter 

You have got things set up in such a way that you are confusing 
autoconfigure. 

Questioner 

What devices have you got in that space, between 320 and 450. 


Peter 

It is not the vectors that are doing that. 

Andy 

I think there is a jump in the CSR space there between the two. 
What AUTOCONFIGURE is doing is seeing CSRs there and thinking 
there is some line printer device, and it is also allocating 
vector space as it is allocating those devices. It goes to load 
the driver, finds there is no driver, this is an unsupported 
device, just keep going. 

Questioner 

So I actually have to configure by hand every device. 

Tony 

A follow up to this very problem. We have a KMS11-PX, the 
single line version of the KMS 11 and if you do an AUTOCONFIGURE 
ALL it very intelligently loads the XS driver whereas PSI 
requires the XN driver. So I did what I did on V3 which had the 
same problem and I did AUTOCONFIGURE ALL/EXCLUDE=XS. It then 
loaded the XN driver. At that point I gave up excluding devices 
and I had to do an AUTOCONFIGURE ALL and select each individual 
device which seems to defeat the purpose of AUTOCONFIGURE ALL. 

Andy 

The algorithm that SHOW/UNIBUS uses, it sniffs around through 
Unibus 10 space and does a test word on a particular location 
and if it finds something there, if memory responds, then it 
says ah ha, you're a DZ, because it knew what it was looking for 
at a particular location. If your special device is in a range 
of CSRs that AUTOCONFIGURE looks at then it is going to confuse 
AUTOCONFIGURE. There are user reserved CSR locations which are 
up above the line printer locations. 

No 17 Jan Schoubo, Denmark 

I should like to modify the print symbiont with the new 
PSM$PRINT routines and write an input field in Pascal. I have 
not yet met anyone who has actually done it although Larry 
Kilgallen says he has some people working on it now. Are there 
any reasons why it should not work, writing this program in 
Pascal, rather than the example in the manual which is in Macro 
and doesn't work. 

Answer 
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I know of customers that have written a modified symbiont in 
Basic and FORTRAN but I don't know what the problems might be in 
Pascal. 

Jan 

Could this end with the suggestion at least that a better 
example might be in high level language next time. 

Answer 

Actually that is on our work program to do that, to give a high 
level language example. You are right that the Macro example 
does not work and we are trying to get that out in the next 
update. 

Jan 

Has anyone in the audience modified symbiont? 

No 18 

Now that the VAX has moved into the mainframe league with 
clusters and 8600s which require somebody to do a system manager 
function, it ought to be possible for this system manager to 
manage mag tape resource allocation. The currently available 
tools - REQUEST, REPLY, MOUNT and ALLOCATE - do not provide this 
sort of function in the way that most people want to do in a 
large tape shop. 

Andy 

We are well aware of the shortcomings and are in the process of 
working up a design for a tape management facility and the like, 
so we intend to provide that kind of capability in future 
versions of VMS. I can't make any promises yet as to how long 
it is going to take us. 

NO 19 Niall Mansfield, Heidelberg VMS 4.0 

In some applications and in languages like Pascal and C, but 
especially in C, you would like to write a primitive that deals 
with relative files, you would like to say, "Get me block N", or 
something like that. The SYS$SPACE primitive gets you a block 
relative to where you are now and the question is is there any 
way to get a relative block from the beginning of a file without 
closing the file and reopening it? In other words you don't 
want to have some global datastructure telling you where you 
were because you are going to call this primitive from all over 
your program. 


Andy 

You want to simply present a record number to RMS and read that 
file. If I remember my RMS correctly, you specify key to access 
and give the relative record number as the key. The capability 
is definitely there. Try and catch me tomorrow and we can go 
through the manual. When I use RMS I usually go to the manual. 

No 20. Mats Jansson, Sweden 

We now have the restart feature on batch jobs. Would it be 
possible to write a program in a way to make it restartable if 
you have a very large computation? 

Peter 

We agree that is a good idea and we will take that back with us. 
DCL does communicate that information, translates the restart 
value call into a send to JBC system service call so you should 
be able to use that supported interface. 

N0 21 Sally Anthill, Vickers WPS/+ utility 

Why are all the keys in different places to KED & EDT? Are 
there any plans to fix this? If not, why not? 

Peter 

The KED and EDT were built with different targets in mind and 
really what we are promoting is TPU as the new editor and TPU 
has the capability of remapping the keys. So does EDT for that 
matter, so they could set up EDT to look like KED. Is the 
person who asked the question in the audience? 

No 22. Mike Waters Rutherford Lab, UK 

Identifiers again. I have set up lots of identifiers as they 
come out of authorisation, two in particular: one called AC750E 
which is set to [1,*] and identifier 750E which doesn't have the 
AC in front of it, set to [1,45], or [45,45] and then trying to 
RUN/UIC=[AC750E,750E] and it fails and 

CREATE/OWNER=[AC750E,750E] also fails trying to parse that 
string. If you use that string on something like DISKQUOTA it 
works fine. It seems to be things with an identifier starting 
with a numeric character. It is not clear whether it doesn't 
always fail. 

Andy 

Well we will have to take that back. I think I can tell you at 
least where the problem lies. The problem is that the 
identifiers and the symbolic UIC expressions are parsed in a 
couple of different places. The place that is accepting it 
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properly, that is allowing you to get it through DISKQUOTA, is 
the $ASCTOID security service. The place that is not working is 
the command line parsing in DCL which does not apparently accept 
all of the identifiers that it should. I will take that back. 

No 23. G P Kristjansson, Iceland, RMS utility 

My programmers claim that there is no way to scroll or step 
backwards in a keyed RMS file. They make a mirror key, they 
take keys and convert them so when they want to scroll backwards 
the program always looks at the mirror key. But it is no 
solution for my programers - they are very heavily loaded. 

Andy 

The answer to that is that we are working on that feature. In 
case some of you didn't hear the requested feature is to be able 
to read in opposite key order in an RMS ISAM file. We are 
working, on that feature and expect to have that available in a 
future VMS release. It is not in 4.2. 

No 24. Peter Holderman 

Written software can make use of the system communication 
service for a high speed task to task communication inside the 
VAX cluster. 

Andy 

At some point in the future it may be possible. At present it 
isn't, for a couple of reasons. First of all we do not provide 
driver access to the system communications layer. Secondly we 
do not even document it at present and the reason is that the 
SCS protocol at the moment is a very new design. We do not yet 
feel comfortable at the moment with its stability. We suspect 
that the SCS protocol is going to change at some point in the 
future as we discover new requirements. In addition there are 
some interesting security problems. The SCS protocol is a 
system internal protocol and as such has no security controls on 
it. Obviously that may not be a concern for a real time 
application. 

Questioner 

This is not a problem for a communication class driver. For 
instance for a standard conventional driver there is no security 
at all. 

Andy 

The point is that certainly we would feel uncomfortable at 
providing user QIO access to the SCS protocol. The difference 
between that and writing a user driver is of course that the 


user driver is of course installed by the system manager. That 
is somewhat different than our just providing access to this 
internal layer of the system. We have had a number of requests 
to make SCS public and so we understand there is a lot of desire 
for it. At present you might consider seeing what you can get 
out of the Cl DECnet, whether its performance would be adequate 
for your needs. 

No 25 Daniele Cuzin, Schulberger EPS, VMS 4.1, 4.2, MSCP utility 

We have a problem on a cluster of four machines with local 
discs. Two of the machines still have local discs and we have 
not found the right way to boot those discs. In fact when we 
boot all the cluster the local discs boot on their own machine 
and all the other machines but if one of the machines which has 
a local disc on crashes or is stopped then when we boot that 
machine the local discs on that machine are not recognised by 
the other machines. This is a problem because we have users on 
both machines on those discs and the only solution we have is to 
mount the discs manually. Is there another way? 

Andy 

I do not completely understand the problem but from my 
experience with clusters I would guess that what is happening to 
you is that on the other systems that are making use of this 
local disc that is served by the system that has gone down, is 
that those other machines are timing out mount verification. 
Mount verificiation is the process that holds IOs to a disc base 
temporarily unavailable until that disc becomes available again 
because, if disc IOs were held, any lock dependencies that 
potentially pile up behind those can also cause other processes 
to hang and, in general, if they are not resolved in some way 
can end up with significant parts of the system bottled up. We 
do have a time out on mount verification and I forget exactly 
what the default is but it is somewhere between 5 and 15 
minutes. If that time out period is shorter than the time it 
takes for the system serving those discs to reboot and get those 
discs back in service, then mount verification will time out, 
the IOs will be failed and the only way to recover the disc is 
in fact to dismount and remount it. So to prevent that problem 
what you have to do is set the sysgen parameter MVTIMEOUT to be 
greater than the length of time it takes one of the systems in 
the cluster to reboot - greater plus some safety margin. 

No 26 

I have got a distribution medium from decatel with a recoverable 
read error on it but VMS install aborted installation. Is it 
necessary to abort installation if it is a recoverable read 
error? 
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Andy 

I would call that a bug in VMSINSTAL and I would take that back. 
VMSINSTAL intercepts the messages that come out of Backup in the 
process of restoring the product save sets. It does that so 
that it can detect certain specific conditions and from what you 
say it sounds to me like it is not properly handling those 
messages coming out of Backup. I agree that if the error is 
recoverable it should allow you to install the kit. 

No 27 h. Kennedy, Oadweald Ltd VMS 4.1 

I was looking at some of the code on security services data 
structures and on the terminal driver came up with the name 
CIA$. That was compound intrusion analysis. I am curious to 
find out where KGB$ comes from and where NSA$ comes from. 

Andy 

You are wondering what possible justification did we have for 
picking those acronyms. KGB is the structure prefix name used 
for the rights database records and it stands for "key grant 
block". NSA stands for "non discretionary security audit". The 
best one of all, which you may or may not have stumbled across 
is the break-in detection list that is maintained by login, 
those blocks are called CIA which stands for "compound intrusion 
analysis". 

Questioner 

Thank you very much, at least someones got a sense of humour 1 
Andy 

Thank you! We haven't quite figured out yet what to do with OSS 
and NKVD. 

No 28 Kurt Jensberg, Switzerland 

We used on VMS V3 the utility "wat". I know that is not from 
DEC, but from DECUS library probably. Is there anything similar 
available on V4. 

Andy 

To the best of my knowledge there are versions of WAT floating 
around the dec engineering net that has been pretty thoroughly 
upgraded to V4 so my guess is that the fellow that wrote it has 
it running on V4 and just needs to be motivated to release the 
new version to DECUS. The guys name is Stanley Rabinowitz. 
Perhaps write to Stan through DECUS and see if you can persuade 
him to ship a new version. It is a DECUS item and not a 
supported part of VMS. 


Kurt 

Are there are plans to integrate that into VMS and make it 
available to everybody. We found it very useful, especially in 
real time application and when you want to look at different 
parameters from different processes it helped a lot and we had 
problems for example with ast limits that were too low and 
processes just hung and with this utility at least we found the 
problems. 

Andy 

We have no plans at the moment to incorporate into VMS, 
certainly it is worth taking back as a suggestion, either that 
directly or similar capabilities. We would want to look at what 
that is providing that some of our existing facilities are not. 

Bob Real, U.S. Air Force in Germany 

I can answer that for you. DEC Munich has taken the old V3 of 
WAT and completely modernised it to completely support on V4. 
It is offered through Franfurt free of charge, you can get in 
Franfurt or Munich. It has complete window encapability, along 
with supporting of just about every function you have under the 
normal SYSUAF. You can display interactively on the new WAT. 

No 29 Daniel Cuzin TA78 utility on cluster 

We have upgraded a TU78 to a TA78 and we have discovered that 
some IBM sysmic tape cannot be read on the TA but could be read 
on the TU and apparently the application program which reads the 
tape uses a code on the TU and we do not have any documentation 
about the TA. 

Comment 

I think we can help you, we have the same problems. Some active 
drivers put some garbage on the beginning of the tape. You 
don't discover it, using Digital tapes but if you write the tape 
on a Digital mag tape station and go to the IBM, then the IBM 
says thats garbage and skips it. 

Comment 

There's another possibility and that's the famous byte swap 
problem. The TU78 drives post byte swap, the TA controller and 
TMSCP protocol do not support byte swap. 

Daniele 

So that means we have to write a program to do the byte swap. 
Why is there not a program. 
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Answer 

As for the documentation I cannot answer that. The TMSCP 
protocol which is supported on HSC controllers, does not support 
byte swap, I mean, why not. 

Peter 

We can take that back for documentation. 

Daniele 

1 have another question. Is it possible to dual port a TA78 on 

2 HSC50. 

Andy 

At present VMS will support static dual porting of the TA78 
meaning that you can hook it up dual ported to the 2 HSCs but we 
will handle the tape drive correctly only if you have only one 
of the ports enabled at any one time. VMS does not yet support 
the proper coordination of the two access paths, so if you are 
willing to use it in a static sense and just change the port 
switches manually, should one HSC go down and use it on the 
other, then you can use it that way. Do not use it with the 
ports set up in both port positions because in effect VMS will 
then see two ta78s in its 10 data base, not recognize that they 
are the same and you will have resulting confusion. 

Daniele 

Do you plan to enable VMS to be able to support two. 

Andy 

It has been suggested, it is one of the things we are 
considering in the future. 

Voice Pchairman 

Two things. First of all we have a TA driver dual ported to 2 
HSCs and it doesn't seem to cause problems. But it is static. 
The other thing was, you said you had taken this back to 
documentation. We would prefer you took it back to your 
developers and changed TMSCP to support byte swapping. We have 
a requirement for that. 

No 31 Johan Hamaker, SRZM, Netherlands VMS 4.1 

I frequently use spawn/nowait/notify/output as some log file to 
do for instance little compilation jobs and that sort of thing. 
Since we have started with V4 I find these jobs die as if they 
have had a heart attack! At unpredictable moments. When you 


look at the log file you sometimes see that the compilation has 
been done but then after compilation has been stopped, another 
time you will see that it has done a compilation and a library 
replacement. Then it has stopped. Sometimes it will run right 
through, sometimes it won't do anything at all. Now somebody 
suggested that there might be a problem there with pooled file 
quota or something like that. That does not sound unreasonable 
except in that case I would expect to find an error message in 
the log file and I don't. 

Andy 

You are saying that there is absolutely no message in the log 
file at all; it just arbitrarily stops. We have not made any 
changes in the way, for example, file quotas or log quotas or 
anything like that are handled. On the other hand with some of 
the changes in RMS the same file operations in V4 require a 
greater enqueue limit. It is conceivable that having gone to V4 
your job is running out on enqueue limit or something like that 
and for whatever obscure reason the error is not being 
reported... 

Voice 

Could he be running into the control Y problem being delivered 
into the subprocess and then they go away and if you don't know 
that happens you have to say input=LAN0, otherwise you spawn and 
you are doing something else and you completely forget this if 
you are used to V3 and you hit control y and the sub process is 
blown away and you never know it? Or am I misremembering 
something? 

Andy 

I wasn't sufficiently familiar enough with spawn to realise that 
was even a problem. But that is an interesting point. 

Johan 

But wouldn't that problem have appeared on V3 as well. 

Answer 

No, we wrote the way control-Y asts are delivered to avoid that 
problem actually. There were a good deal of trouble in V3 with 
out-of^band characters and spawn processes and we did a good 
deal of work to clean that up. It may be that there is a hole 
there. I suspect if there is that the DCL person has gotten 
complaints and by 4.2 it will be fixed. If you still see this 
in 4.2, try and get a little more data together to send us. 
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Johan 

I would have been willing to send an SPR but I would have no 
idea what supporting documentation to send. 

No 33 Jaume Sole, G.D.S., Barcelona VMS 4.1 

It's a dual system, 2 VAXes 2 750s connected with Ethernet. 

System hangs for 2 to 3 minutes. After doing nothing, activity 
continues normally. During the hang there is no control c, no 
control y response, no echoes prompts, no user name prompts, no 
spool activity, typeahead does not work meaning the characters 
are lost. 

Andy 

The fact that the typeahead characters are being lost means that 
the system is going into a loop at rather high IPL. Jake 
suggests that it might be a false power fail problem, something 
to that effect. It is conceivable that the Ethernet interface 
is misbehaving and is causing the driver to become sick which in 
turn might cause a lot of execution at driver IPL which is the 
kind of thing which would block this activity. To analyse this 
sort of problem, we really have to catch the system in the act, 
force a crash and then analyse the crash dump. 

The other thing to look at is, if possible, does the problem 
persist while the net is shut down, something like that, see if 
you can isolate the cause by isolating components. 

No 34 (no name) 

In VMS 4.1 there was a patch to COBRTL.EXE which I believe is 
part of VMS not COBOL that fixed an apparent buffer overflow 
problem in display verb. The fix increased the buffer 
allocation from approximately lk to 64k bytes on the user stack. 

I have an application that multithreads with a p user stack 

stuffed in a global section. The problem is that my TSC say 
that this fix is not a problem. I find 64k of stack for an 

output buffer is a little bit excessive. I think it's ECO no 1. 

Incidentally perhaps the guy who wrote the patch should have 
started out on PDPll then he would appreciate what 64k bytes 
were. 

Andy 

Unfortunately we have no representatives here from the 
organisation responsible for either COBOL or the run time 
library, so I think the best we can do is to take your comment 
and basically ask them what's all this then. 
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No 34 

Just as a side point on the same matter, is there any other 
thing that any of the panel know of that is COBOL from a user 
program which will allocate an excessive amount of stack. 

Andy 

There is none that I know of but then I am not familiar with 
most portions of the run time library in general. The code in 
the base VMS system and most of the base library modules 
allocate stack that pretty much amounts to what they really 
need. 

No 35 (no name) 

A machine having a UDA50 and a Versatec 121 DMA interface on the 
same Unibus regularly clashes with all sorts of different 
bugchecks. Field service say this can be caused by an incorrect 
delay setting on the UDA. Have we got a hardware man that can 
tell us what a delay setting could be doing. 

Panel member 

My first answer I Depending on the memory band within the 
buffering characteristics of the device, if the device under 
question does not have sufficient internal buffering it is 
possible for UDA to dominate the 10 bandwidth of Unibus. There 
is a setting on the UDA which is hardware settable to delay the 
time that the UDA will vie for arbitration of the Unibus. By 
default I believe it is set to 6.2 microseconds which means that 
it will pause for that length of time before arbitrating again 
to gain control of the bus. It could be that the other optional 
settings are zero microseconds and 10 microseconds. I think it 
is worthwhile for the hardware service representative to have a 
look at that and make sure there is sufficient bandwidth left 
for the other devices on the Unibus. 

No 36 Peter Humble, Leicester University 

From time to time we get problems with an interactive user 
running a job which really ought to be a batch job and is just 
sitting there in compute for hours and hours on end, somewhat 
'ogging the machine. With the exception of restricting the CPU 
time available to anybody, in the SYSUAF for example, or 
spending some time whenever we see it has happened to try and 
find out who has done it and sort something out personally, is 
there any mechanism to make it difficult for them to do this 
sort of thing, and if not, would it be a good idea if something 
was in there, for example some sort of dynamic lowering of base 
priority for people who didn't do any io to a terminal from an 
interactive job. 
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Peter 

Well the system does have some dynamic lowering of the priority 
in that when you do 10 you in fact get a priority boost. Now 
obviously whether this is a serious problem or not depends on 
how you have your batch keys configured. If you are running 
your batch queues at a lower priority, let us say priority 3, 
then clearly doing heavy compute down work for an interactive 
session would constitute abuse of the system because it would 
seriously interfere with the batch jobs. I think the real 
solution for this requires a class scheduler which is something 

that would actually allow you to allocate CPU time in a 

proportional way between the service classes. That would in 

fact allow you to make sure that an interactive user could not 

get more than a certain share of the CPU. We are looking at 
that kind of scheduler for future VMS versions. At present what 
you can do is put a CPU time limit into the users UAF record 
which limits the amount which he can accomplish in one login 
session and then override that with a larger CPU limit on the 
batch queue, so that jobs requiring larger amounts of CPU must 
then be run through the batch queue. Of course the other thing 
that you can do is filter the accounting records, looking for 
interactive logouts that have accumulated a large amount of CPU 
time which is what you referred to in terms of chasing after the 
matter personally. 

Comment 

It has been noted to me that some people put ACLs on certain 
images so that they only can be run from batch so if it is 
running the compiler for example, and you don't want compilers 
run interactively, you could put an ACL on the image for the 
compiler. 

Questioner 

Unfortunately it is nearly always the users own application. 

No 37 Ugor Ergun, Turkey 

My company is the representative of DEC in Turkey. One of our 
customers wants to use C for their transaction processing. Is 
it easy (as in COBOL) to handle RMS organisations in C. How 
does C compare with COBOL. 

Andy 

It is not that difficult to do RMS from C and the documentation 
is pretty good. C will work in the transaction processing 
product that we support acms so I think all that is possible and 
not that difficult. 


No 38 (no name) 

How is it possible to make printers (connected via serial tty 
lines) available from other VAX systems connected via Ethernet? 

Answer 

I think all I can say on this question is that we have some work 
going on to potentially extend the capability of the lab server 
to support remote printers, such that a connection could be 
established from that host but that support is not here 
currently. 

No 39 Terse Grevle, Norway VMS 4 

When will the function 'delete to end of line' be implemented 
(or is it already)? 

Peter 

Probably never. It was not a matter of being so much code or 
something like that but the work that we did with our line 
editing staff was the result of a human factor study done within 
Digital for what novice users need to get by with the system 
editing functions. All of the things that we did were based on 
that study. Although it is not as powerful as EDT there is not 
as much code there. We think we have a good balance between 
usability and the functions that we provide so we do not plan at 
this time to add any more functions. 

Andy 

One of the things that I would like to add is that one of the 
results that came out of that human factor study is that one of 
the important aspects of the command line editing was that it be 
simple and therefore it was important that we only provide the 
minimum set of functions necessary and not clutter up the 
keyboad with a lot of fancy editing functions that people would 
not use very often. 

No 40 

This may be a hardware problem but I will go anyway. I have an 
VT200 which I use in VT100 mode because thats all my iden will 
support and I have to login into some DEC systems which do a 
SET TERMINAL/INQUIRE. And SET TERMINAL/INQUIRE on a VT200 in 
VT100 mode sets the terminal to VT200 and my terminal starts 
speaking me in Swedish. I have enough problems in English, I 
can't answer in Swedish. If the VT200 is set to VT52 mode and 
you do SET TERMINAL/INQUIRE it stays in VT52 mode. Where is the 
bug. 
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Peter 

The VT200 tells us even when it is in VT100 mode that it is a 
VT200 and so VMS says ok f you are and if it is in VT100 mode 
becomes a VT200. We do that because it is the only way that the 
characters that SET TERMINAL/INQUIRE sets up can be truthful, it 
tells us that it has soft characters and various things and 
unless we force it to VT200 mode we can’t really guarantee 
applications that those characteristics are there. We 
complained to terminals engineering about the design and they 
didn't listen to me and the VMS group. The customers complain 
and they listen to the customers, so you can get a v2 of your 
VT200 microcode which will allow you to change the set up to 
answer back VT100 when it is in VT100 mode. So contact your 
local office. 

Comment 

Do not change our terminals because they turn into English! 
(Swedish gentleman). 

No 41 Jean Yves Le Poec 

Have you got any plan to support Ethernet on stand-alone Backup. 
If you crash the MicroVAX you have to reload up the 50 floppies 
and Ethernet stand-alone Backup you would only have to load 
stand-alone Backup and then take it over the Ethernet. 

Andy 

We do not have any plans to do that. The real problem with that 
is the amount of mechanism necessary to get the network up. To 
use the Ethernet in stand-alone Backup we need a lot more than 
just the NI driver, we also need all of DECnet because that is 
how Backup accesses its files over the net. I think at that 
point we also need RMS which is not in stand-alone Backup. We 
end up with a large number of system components that are 
currently not there and I think all told we would probably about 
triple the size of the stand-alone Backup kit and if you think 
booting it off tu58s is bad now... What it boils down to is 
that stand-alone Backup runs in a very restricted environment 
and any changes of that sort require very substantial extensions 
to the environment which are of a magnitude as to be 
impractical. In terms of MicroVAXs on Ethernets failing and 
getting the software serviced we are looking at some other 
options. I think it is premature to talk about some of the 
things we are thinking about but there is work going on in that 
area. 

No 42 Hans Magneson, Sweden VMS 4.1 


On our system we have set up the printer with the flags feed and 
flag page and when users want to get rid of this flag page then 
they qualify no flag but nothing happens on the printer, it 
still has a flag page. 

Peter 

Then you initialize a queue there is a qualifier called 
/SEPARATE which takes a key word list and it can take a flag 
burst trailer type keywords and this represents the flag burst 
and trailer pages which will be put on the job. On a job wide 
basis. There is a separate qualifier on the queue commands 
/DEFAULT which takes the same keywords and this pertains to the 
file level flag separation and trailer pages. Now the print 
command also has these qualifiers as distinct qualifiers 
including feed and it is able to override the setting specified 
with the /DEFAULT qualifier on the JNIT QUEUE. That is, your 
print command can override the flag on the file level separation 
page policy but it can not modify or change override that which 
you have set up for the job. 

End of tape, part of speech missing. 

Continues in middle of speech. 

- because of the buffer, I am guessing but that is probably what 
it is. The host system where you set host to is probably in the 
same range, it is the QIO that the application does which it is 
going to have to do anyway and then a DEC 10 every now and then 
but that is not even a QIO, thats an internal IRP mechanism 
which is very efficient. I don't think that the overhead is 
that severe, especially with V4 so I wouldnt worry about it. 

Comment 

Just a couple of additional comments with file transfer. The 
overhead on our micro7 70 for doing a sustained file transfer 
operation, I am talking about say a thousand block file where 
you are not worried about the overhead for opening and closing 
and connection and all that stuff is really not too bad. I am 
trying to remember this. On 2 780s with Ethernet connection 
where there was nothing else really going on, I was able to get 
sustained file tranfer rate of approximately half a megabit. 
The maximum that you can get with task to task file transfer is 
a little over 1 megabit over Ethernet cable. You are really 
limited by the transceiver. Now there is a special case, and 
that is with MicroVAX in that there is a end to end CRC check 
done between RMS and the remote file and on the MicroVAX, 
MicroVAX 1 in particular, where the CRC structuring is emulated 
it can soak up quite a few cycles on a systeme file transfer for 
that MicroVAX. But then again you are probably in a single user 
mode there and it is probably not that important for you. 
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Also, just on file transfer is that there is a parameter, SET 
RMS DEFAULT command that you can use to specify a parameter 
called network block count I believe and that is a parameter 
that RMS uses to determine how big a QIO it should issue when 
doing a block mode file transfer and I think we set that to 8 
blocks by default which is quite sufficient. 

No 45 G S Bal, University of Liverpool VMS 4.1 

The terminals which used to log out and drop the lines on the V3 
do not work on V4. Earlier a mention was made of system 
parameter TTYDEFPORT and if I heard it correctly, you set the 
lower bit value to 1. If I were to do that can I have an 
assurance that it would restore the behaviour of the terminal 
handler to the same level as it was on v 3. 

Andy 

It restores the behaviour with respect to the class driver, it 
doesn't tell the port driver to turn on auto xrx. Is that what 
you think your problem is. 

G. Bal 

My problem is that if the terminal is switched off and the Ids 
box switch is switched on and the contention device my session 
stays on but I would like to terminate my session. 

It used to work on the 3.7, if you could hold the line 
independently for 25 to 30 seconds the system used to kill the 
process, which I could control from the contention device, not 
activate that device for the next 30 seconds. 

Andy 

Okay, basically you are saying that the gandalf hangs up but the 
VMS doesn't. There are no known problems in this area in VMS 
and haven't been since V2 I believe. Anything that is a hang up 
problem is generally traced to a hardware or wiring problem. 
There is one thing you could modify, that is tty dial type. If 
you set the low bit of that it shortens the amount of time that 
it actually cancels the terminal drivers debouncing of carrier 
signal, so that if it sees carrier go at all it will drop the 
1 ine. 

Larry 

There is a problem associated with the upgrade to V4 in that it 
destroys your default modem settings in your default hang up 
settings and everything if you had them in the default 
characteristics word for the tty. It could just be in the 
transition that those things need to be set up again, in your 
default terminal projections. 


G bal 

All the lines have been set up with modem signals and even we 
tried the other day with a /DISABLE, and that didn't work 
either. 

Andy 

This is a thing where you really have to get a breakout box and 
play with the signals and get a field service tech out there to 
check your wiring and that sort of thing. 

No 46 N. K. Mooljee Edinburgh University 

Some computer systems that I know and very often in a university 
environment keep a record of terminal dialogue between user and 
computer in a physic file if the user so chooses. Is DEC 
seriously considering this question or the provision of such a 
facility for interactive users and is there a way of getting 
round this problem at the moment. 

Andy 

SET HOST/LOG 0, which will log you in on the local node and keep 
a log file of the events that happened while you were logged in. 

Nerris 

And this is a user facility which any user can use. 

Andy 

As long as you have DECnet running. That is a part of DECnet 
you can use without having the DECnet licence. SET HOST/LOG 0, 
no name, just gets you back to the same node and that will allow 
you to do that. It turned out easier to do it there than in the 
terminal driver so that was the quick fix. 

No 47 P V Diennen ITT, Netherlands 

I think it is question pertaining to the REPLY/LOG. We try to 
print out the operator log at daily intervals and we do that by 
a batch job that runs daily. If the operator logging is active 
you can't print the file so we have to re open the file using 
REPLY/LOG. This is not working from the batch. It returns 
successful but it does not do anything. In a desperate moment I 
turned on all privileges but it doesn't help. 

Andy 

I don't see anything on the face of it why this shouldn't work. 
We will have to take this back. Shouted comment, couldnt hear 
it. 
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Andy 

The comments from the floor are that the REPLY/LOG command must 
be entered from an operator terminal, that is a terminal that 
has been enabled as a operator terminal and obviously a batch 
job is not enabled as an operator terminal. The work around for 
that is that the reply command uses the logical name SYS$COMMAND 
to direct what the operator terminal is that it is working 
against so by doing a logical name definition, say, define 
SYS$COMMAND OPA0: I believe you can make that work. For 

example thats how we enable OPA0: as an operator terminal from 
the system start up file. Because the system start up file is 
in effect a batch job, we do a define SYS$COMMAND OPA0: 

REPLY/ENABLE so I am not going to guarantee it but it sounds as 
if that is the sort of thing that should solve the problem. 

No 48 no name 

When we reboot 8600 after a crash or a shutdown/reboot we get 
the message "micro-code not up to level required for VMS" we 
watch it and it continues to boot and seems to run okay without 
any problem. So we called in our engineer and he said it's okay 
it's not a problem, but we had him check it out and he came back 
and said the Cl microcode is too advanced for VMS. So we 

changed it for an old version of Cl microcode and in the next 
boot the message was still there. We did notice that when you 
do a boot from the console in console mode the message does not 
appear. We would like to know where the message is coming from 
and should we worry about it. 

Trudy Matthews 

It has nothing to do with the Cl microcode. Actually VMS during 
bootstrap will enquire of the CPU (in the 8600) that the console 
keeps the microcode version and so we enquire of the console 

what the current microcode version we expect. However there is 

a bug in the 8600 console microcode which will be corrected with 
the next update of the 8600 console microcode in that at times, 
and I can't even remember under which circumstances, it will 
give us back a wrong value for the microcode. But it is really 
safe to ignore that message. 

Again, end of tape, part of conference missing. 

Continues: 

Andy 

How much of a program is this that is required to reproduce 
this. 


Questioner (unknown) 

Well unfortunately some of the tools were written some time ago 
and we don't have the original source code for it. Program is 
about 700,000 lines of FORTRAN. 

Andy 

Boy you got me. The only idea I have is get it in that state 

and take a crash dump and send us the details of what the 

application is trying to do in terms of qios and so forth, the 
general philosophy behind the program maybe. And also include 
which DZ line was hung so we don't have to go all through the 
dump trying to figure out which terminal line was hung, that is 
a big help, and we will take a look at it, but it doesn't sound 
like the kind of thing we will be able to track down. 

Questioner 

Our operators tend when they shut down the machine, to start 
using carriage returns, and when you are in a cluster 
environment and you do that, if you don't type in "REMOVENODE" 
then you end up with a hang in that cluster until they all 
decide that that node is indeed shutting down. I recommend that 

you put a little check in the shtudown and if the node you are 

shutting down is a cluster member, make the remove node the 
default. 

Comment 

I have a comment on this gentleman's question. I have some 
problems with a DMF32 port, the first two ports on it have the 
full modem control and I have also a small problem in the source 
code, but it won't run on the first two ports of DMF32 because 
of some changes in the driver. I have had spoken to the field 
service engineer and he was pretty sure that the changes in the 
driver were the cause of my problem. I have changed to another 
port. 

Andy 

Do you know offhand what the rev level of your DMF is. 

Commenter 

No. 

Andy 

There are no problems known with the current VMS V4. 
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Commenter 

Actually I can fix it in my program, quite easily, I have to do 
something which I didn't have to do earlier, so it was just an 
inaccurate program at first and so now I have to improve it a 
little to make it work on the first two ports. It may be that 
the problems look alike. 


time out can not be modified... it is built into the Cl 
microcode. So the best you can do is to try to avoid hitting 
that time out. For example when you reboot a machine, in 
particular, give it an unjam command which immediately shuts 
down the Cl port and eliminates that time out interval. Beyond 
that you are right, the next time out is the reconnection 
interval so you can shorten that up and then that will shorten 
the time it takes to fail the machine out of the cluster. 


Andy 

It is my understanding that very old versions of DMF like rev C 
or rev d of the microcode in the DMF did have the same XON/XOFF 
problem but if you are on a field service contract you should be 
way beyond that at this point. 


No 58 

Is it a problem, to shorten down this value? 
Andy 


Another comment (no name) 

I have a similar problem with a DZ11 port hooked up to a 240. 
Under certain circumstances, especially when it is in VT52 mode 
the VT driver crashes the VAX, and it does it consistently. It 
works for a while and then all of a sudden several pages of 
garbage are sent to the terminal and it crashes. 

Andy 

We fixed some strange conditions in the DZ driver, I think it 
was in 4.1 but maybe it's 4.2. 

No 58 (no name) 

In a cluster when one member dies for any reason the other 
members are stopped for a while. What can be done to decrease 
that dead time. 

Andy 


The only problem that you can run into is that you increase your 
exposure to things like transient power failures or potentially 
transient communications failures, lets say, something goes 
wrong for a few seconds with the Cl communications or lets say 
that the machine looses power for a very short period of time. 
Normally we ship it with reconnection intervals set up so that a 
very brief power outage will allow the machine to remain in the 
cluster. Of course the problem is that while that machine is 
out the rest of the cluster has to wait for it to come back. If 
you take the other option of shortening the reconnection 
interval, then if the machine takes a power failure, it will 
immediately leave the cluster, but it cannot re-enter. It means 
that the machine must then be rebooted, even it managed to 
survive the power fail. That is really only the significant 
negative effect of shortening re connection interval. 

No 61 Bojan Dremelj, Yugoslavia, VAX/VMS 4.1 

Why does the error command not work as it is described in the 
help facility? 


In this case are you actually getting a crash, or is it stopping 
and rebooting? 

No 58 

I booted one voluntarily to see what happened on the other one 
and the other one stopped doing anything for 50 to 60 seconds. 

Andy 

When you simply stop and reboot a node, one of the problems that 
you can run into is that the Cl port hardware has a 99 second 
timeout on its virtual circuit. Usually an unjam command on a 
780 will break that virtual circuit. However, lets say the 
operating system simply hangs or something like that, then there 
is a 99 second timeout in the Cl port, after which the Cl port 
finally gives up and decides that its processor is dead. That 


$help errors...for a more detailed explanation of the error and 
suggestions for error recovery, type error followed by the ident 
portion of the error message... 

$error ident...%dcl-w-iwerb, unrecognised command.../error/ 

Andy 

That certainly sounds like we left some loose ends in our help 
file. The help files are prepared by our documentation group, 
we will have to take that back to the documentation group and 
ask them what is going on. I think what has happened is that 
you have been led astray by a very minor error in the help text. 

Clearly the way it should work to find help on a particular 
error message is that you should say.."help error" and then the 
error identification rather than simply error identification. 
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That doesn't work either. 

Trudy Matthews 

According to the UK TSC it never did work and the entry pointing 
you up to it is removed at V4.2. 

No 63 W Kegel, Dynaflow Software Systems, Holland 

I have processes having sysprv privileges for various reasons 
and up to V3.7 those processes were creating files specifying 
uic [0,0], they would be created on the user's account. As of 
V4 they are created on the owner of the directory instead. My 
question is this a temporary process or is it going to go away. 

Andy 

This is an intentional change. This is part of the new 

ownership and protection defaulting rules in the file system. 
In general, we felt that it made more sense to default the file 
ownership to be the ownership of the directory that you are 
creating the file in, provided that the person creating the file 
has the privileges to charge space to that UIC. For example 
what that does, is it allows the system manager to create a file 
in some user's directory and have that file be owned by the 
user. This is the sort of rationale, we felt it was a more 

consistent way for things to work. We apologise for the 
inconvenience. We made the change feeling that a greater number 
of users would benefit from it. 

W. Kegel 

Then I would suggest that you do something about your 
documentation because your documentation just says that you need 

sysprv to create a file on another account on your own but it 

doesn't state that if you have the privilege it will be done. 

Comment 

The documentation was fixed in 4.2. 

No 65 Larry Kilgallen VMS 4.2 

What is the policy regarding distribution of VMS 4.2 source kit 
updates? 

Andy 

There will be V4.2 source kit. The last I heard, the 4.2 
project leader was still banging his head against the wall, 
getting the thing to build properly. 


Larry 

That's a technical question Andy. The real question has to do 
with whenever it happens. 

Andy 

It is our intention in the future to provide source kits for the 
functional updates. 

Peter (I think) 

For 4.2 in particular, I believe it is going to be an update to 
the 4.0 source kit as opposed to a remastered source kit. 

Larry 

What I am really trying to do is dance around the forbidden 
issue of prices. People who already bought a 4.0: Will they 
get this... 

Peter 

We talked to our product management about that, we being the 
people worried about trying to put the kits together. 

Larry 

I have the greatest faith that they will get the kit together, 
it is just getting it out to the field that I am questioning. 

Peter 

It is under discussion from what we can see and there will be 
resolution shortly. 

Andy 

It turns out, Larry, that I was just recently looking in the 
price book about source kits anyway and noticed that even for 
4.0, the upgrade price from V3 is considerably less than the 
price of a new source kit, so without knowing any of the 
details, never mind mentioning them, I would guess that we would 
do something similar. 

Larry 

To repeat something that has been said before, regardless of how 
much money you hope to make out of source kits, it would be a 
lot nicer on our end if it were a monthly charge that we pay 
forever, because we can sell that to management. We never know 
when VMS is going to come out and having to, all of a sudden, 
when the stuff comes out, run in and get a purchase 
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authorisation is a lot more cumbersome. Certainly with doc sets 
we pay a certain amount per month, never knowing how many pages 
we are going to get per dollar how often, and if a similar 
policy could be instituted for source kits it might be nice. 

Peter 

That is a very good suggestion and we are looking at some of the 
licencing policies and that is one of the alternatives. 

Larry 

Someone else in the organisation might like an even revenue flow 
as well, regardless of whether software is produced, and that is 
one way to do it. 

No 66 (no name) 

We occasionally have processes having an outstanding read on the 
mail box and we then ask them to terminate by means of a $FORCEX 
system service. That worked fine until 3.7 but then all of a 
sudden those processes didn't go away any more. Instead they 
returned an 10 error which, after the usual fiddling around, 
trying to convert a FORTRAN 10 error to a system service error, 
we found to be "activity precludes operation" and the exit 
handlers are never activated any more. Can you explain why? 

Andy 

You are using RMS to read the mail boxes? 

No 66 

Implicitly. It is a FORTRAN read. 

Andy 

I don't remember the details, I know we went through some mayhem 
in getting RMS rundown to work correctly and I know it has been 
changed several times. It has to do with RMS keeping track of 
whether or not there is 10 on a particular RMS open file at the 
time you are doing rundown. The problem is, you enter your exit 
handler and you are now attempting to do 10 on an RMS channel 
that already has 10 pending. I believe what is likely to have 
happened in 3.7 is that they tightened up some of those checks, 
where you used to get away with things that maybe you were lucky 
with, but in other circumstances can crash RMS and I know we 
have been tightening up the checks on that sort of thing 
recently. 

No 66 


I am pretty sure that it doesn't enter my user written exit 
handlers. All those processes have one, I force one to be there 
by doing LIB$INITIALIZE. 

Andy 

I think we are going to have to have an SPR and some 
documentation on that. I think it is too complicated for me to 
deal with here. 

No 66 

I did a work around by using a $DELPRC instead which worked 
f ine. 

No 67 Bengt Eriksson, Stockholm County Council, Utility: Backup 

Normally when a user makes a mount request that request is of 
course spread round to all the terminals that have been enabled 
as operator terminals but when I perform backup, and especially 
backup onto a tape station which requires many reels of tapes. 
Backup issues the message 

%BACKUP-I-READYWRITE, please mount next volume 

or something like that, but that message is not broadcast round 
to other terminals. That has the consequence that I as system 
manager have to be in the vicinity of the terminal or the 
console from where the backup is invoked. It would be very 
handy if I could sit in my own room and just go into the VAX 
every now and change tape reads. Is that possible? 

Andy 

That is a worthwhile suggestion. Backup in fact has the logic 
in it to use the operator request for tape mounts and at present 
it is coded so it only uses that when you run it in a batch job. 
I think that is a worthwhile suggestion, we have heard it in the 
past, that there at least be a qualifier to cause it to use the 
operator messages for tape mounts. It was done the way it was 
done originally, based on the assumption that things like 
multitape backups would most likely be done by operators who 
would be logged in near the tape drive anyway. That assumption 
holds true in many cases but obviously not all. 

No 69 David Roberts, Univ. of Leicester, VMS 4.1 mag tapes. 

I have no need to ask the question, because the question was 
answered in a different form earlier on. 

No 88 (no name) 


VAX-58 


VAX-59 
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This one is so simple that I am sure it must have been asked 
before in some context but I did not hear the answer. Is there 
ever going to be in SYS$ACTIVATEIMAGE service, which will do 
just the image activation, nothing about creating processes or 
spawning etc? 

Andy 

Obviously that service exists and so what it really boils down 
is when are we going to get round to be willing to document the 
thing. The answer is as soon as we feel that we have the 
interface to that service frozen. We have in fact changed the 
interface to the image activation service a couple of times as 
we have added features to the image activator. Because we feel 
that the interface is not fully stable yet is why we have not 
documented it. Obviously documenting it means committing to 
that service. We do plan to stabilise that at some point in the 
not too distant future so that we can document it. 

No 88 

Would it possible to map images and call them as subprograms but 
we couldn't recover the space? 

Andy 

What you want to do is recover the space after the image. That 
turns out to be very very difficult. At least from the point of 
view of the system, because once you have activated a sharable 
image or whatever and called into it, there is really no way for 

VMS to tell that that image has become truely idle. It is 

possible for it to have any number of ASTs outstanding for 

example, because of terminal driver events or whatever. 

No 88 

Is that true if it is a subprogram? 

Andy 

Well no, thats not true because subprograms can have side 
effects that last way beyond their invocation and about the only 
thing we can recommend is that, in the case where you have done 
that, you know the piece of address space that that has been 
loaded into. If you want to get rid of it do a $DELETVA on that 
address space and then it is your responsibility. Then 
something has gone wrong. In fact you deleted the address space 
when the thing that you were using was not fully idle and that 
is exactly the kind of problem that we feel unable to solve. 
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A form for 
the issue. 


Caption: 
Message: 


Contact: 


Date: 


INPUT/OUTPUT 


A SIG Information Interchange 
INPUT/OUTPUT submissions is available at the back of 


INPUT/OUTPUT 486 

TeX DVI post-processor for terminals 

We are looking for a way to direct TeX output to a 
terminal, rather than to a hardcopy device. Ideally, 
this could be routed to a high-resolution graphics 
terminal (i.e., Tektronix 4107), but support for ANSI 
(VT100) terminals would suffice (not supporting 
special features, just the text). Does anybody have 
this capability or has anybody heard of it? 

Mr. Brian R. Shamblin 
Medical Sciences Building 
Mayo Foundation 
200 First Street Southwest 
Rochester, MN 55905 
Telephone (507) 284-4069 

February 12, 1986 
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DECUS PROGRAM LIBRARY 


NEW LIBRARY PROGRAMS AVAILABLE FOR THE 
PROFESSIONAL-300 SERIES OF COMPUTERS 

DECUS ORDER NO: PRO-1 48, Title: KERMITforP/ 
OS, Version: December 1985 

Submitted by: G. Thomson, PRAXA, Jolimont Vic¬ 
toria, Australia, 3002 Operating System: P/OS VI .7. 
Source Language: MACRO-3, Memory Required: 
512 KB 

Abstract: Kermit-11 on the PRO-3xx allows for a stan¬ 
dard form of file transfer from these systems to about 
120 other implementations of Kermit on other sys¬ 
tems, including the PDP-11, VAX, DECsystem 1 0/20, 
Rainbow-100 and other manufacturer's equipment. 

Two versions are provided — one menu orien¬ 
ted and the other command driven. 

Sources not included. Documentation on magnetic 
media 

Media (Service Charge Code): One RX50 Diskette 
(JA), Format: FILES-11 


NEW LIBRARY PROGRAMS AVAILABLE FOR THE 
DECmate II 

DECUS ORDER NO: DM-11 0, Title: DECmate 11 & 111 
Games, Version: 1.0, December 1985 

Submitted by: Digital Equipment Corporation, Operat¬ 
ing System: OS/278 V2.0, Source Language: BASIC, 
Memory Required: Standard System 

Abstract: Tired of processing words and spreading 
spreadsheets? Then you are ready for the“ DECmate 
II & III Games Diskette”. You can play Blackjack 
(watch it; thecomputermightcheat), possibly be king 
for a day (don’t forget to feed the people), or travel 
through space (look out for the Klingons). 

This menu driven package brings you some 
relief from the hassle of the everyday routine. Everything 
you need is on one diskette. Just boot it up and 
ENJOY!!! 

Remember, all input must be uppercase (use 
the LOCK key). 

Complete sources not included. 

Documentation may or may not be on magnetic 
media 

Media (Service Charge Code): One RX50 Diskette 
(JA), Format: OS/8 


NEW LIBRARY PROGRAMS AVAILABLE FOR THE 
PDP-11 COMPUTER FAMILY 

DECUS NO: 11 -81 7, Title: SETDTM — Set Date and 
Time Utilizing Digital Pathways TCU-150 Clock, Ver¬ 
sion: VI .0, November 1985 

Submitted by: John C. Gibbons, Macedonia OH, 
Operating System: RT-11 V4.0 or later, Source Lan¬ 
guage: MACRO-11, Memory Required: 581 Words 
Special Hardware Required: Digital Pathways TCU- 
150 UNIBUS Clock 

Abstract: SETDTM is a program designed to read the 
Digital Pathways, Inc. TCU-150 battery operated 
UN I BUS clock and set the system date and time 
accordingly under the RT-11 V4 or later monitor. 

The TCU-150 has the hardware capability of 
providing the Julian year, month and day as well as 
the hour, minute and second. Leap years are accoun¬ 
ted for by the TCU-150 in hardware as well. 

This program employs a uniquefeature in that it 
also provides for an optional Daylight Savings Time 
(DS7) set-ahead (typically in the Spring) by manually 
setting a storage location (DSTFLG) in this program 
to a non-zero value. This allows the user to account 
for the time change WITHOUT resetting the clock 
registers intheTCU-150 directly. Leap years arealso 
accounted for when there is a month roll-over for the 
DST calculation. Indirect command files are pro¬ 
vided with th distribution to accomplish the task of 
changing from Standard Time to Daylight Savings 
Time and vice versa. 

Constants are also provided in the source lis¬ 
tings to accomodate the use of either the 50 HZ or 
60 HZ line frequency clocks. The distribution has both 
50HZ and 60HZ versions already compiled for the 
users convenience. 

Documentation on magnetic media 

Media (Service Charge Code): User's Manual (EA), 
One RX01 Diskette(KA), Format: RT-11,600’, Mag¬ 
netic Tape (MA), Format: RT-11 

DECUS NO: 11-818, Title: Programs from ‘Statistical 
Computation', Version: December 1985 

Submitted by: J.H. Maindonald, Applied Maths Div, 
DSIR, Auckland New Zealand, Operating System: VAX/ 
VMS V4, RT-11, V5, Source Language: BASIC-11, 
Memory Required: (MULREG& NORMEQ) 18500B, 
other programs much less 

Abstract Apart from one omission and three additions 
(marked with *), these are the programs listed in 
chapters9 and 10 of Maindonald, J.H.(1984): ‘Statis¬ 
tical Computation’. Wiley, N.Y. 


Included are: 

• MULREGand NORM EQ: These two alterna¬ 
tive programs use modern algorithms to han¬ 
dle multiple regression calculations. M U LREG 
uses Givens rotations, avoiding NORMEQ’s 
explicit formation of the normal equations. 
There are minor improvements on the lis¬ 
tings in‘Statistical Computation’. 

• GAMMA*: Evaluate log n! 

• GAUSS*, GAUSS1, GAU12, GAUSS3, GAUSS4, 
andGAUI5: These approximate the cumula¬ 
tive normal or its inverse. 

• CHISQ6:Approximates the cumulative chi- 
square distribution. 

• TDIS7 and TINV8:Approximate the cumula¬ 
tive t-distribution and its inverse. 

• F*and FDIS9:Theseapproximatethe cumu¬ 
lative F-distribution. 

• FDIS10: Approximates the non-central F- 
distribution. 

• BIN LI M: Approximate binomial confidence 
limits. 

• COR RE L Confidence limits for the product- 
moment correlation. 

• SVD:Singular value decomposition, using 
Nash and Lefkovitch’s modification of method 
due to Kaiser. 

Documentation on magnetic media 

Media (Service Charge Code): One RX01 Diskette 
(KA), Format RT-11,600’ Magnetic Tape (M A), For¬ 
mat RT-11 


DECUS NO: 11 -825, Title: Plot Calendar, Version: VI .0, 
December 1985 

Submitted by: William W. Sugg, Defense Mappping 
Agency, St Louis MO, Operating System: RSX-11 M V3.2, 
Source Language: FORTRAN 77 Memory Required: 
25504 Words, Software Required: Versaplot Sub¬ 
routines Special Hardware Required: Versatec Plotter 
8236 or larger 

Abstract: Plot Calendar(PC) will plot a 12 month calen- 
car on a Versatec or similar plotter. PC will accept years 
from 1 583 to32766 and a leap yearcheck will be made 
for whatever year is entered. Each month will be plotted 
to a size of 8.75 inches in the X direction and 9.00 inches 
in the Y direction. The plotter must have a minimum X 
plotting range of 50.0 inches and a minimum Y plotting 
range of 32.0 inches. 


The user is allowed to annotate from 1 -365 days of 
the year. Each day may have up to 6 lines of annotation 
with up to 1 5 characters per line. PC runs on a PDP11 / 
44, RSX-11 M version 3.2 operating system and with the 
Versaplot software version 07, edition #5, dated October 
1 978. To run the PC program, 25504 K words of memory 
are needed and two files are generated when the an¬ 
notation option is picked. 

Restrictions: Plotter must be able to plot at Ieast31 ” in Y 
direction and 50” in X direction. 

Documentation on magnetic media 

Media(Service Charge Code): OneRXOI Diskette(KA), 
Format: FILES-11,600’ Magnetic Tape (MA), Format: 
FILES-1 


NEW LIBRARY PROGRAMS AVAILABLE FOR THE 
VAX/VMS FAMILY OF COMPUTERS 

DECUS NO: VAX-152, Title: MOVE__PASSWORD 
Utility, Version: November 1985 

Submitted by: Tom F. Coe, Naval Weapons Center, 
China LakeCA, Operating System: VAX/VMS V4.2, 
Source Language: MACRO-32 

Abstract Software Required: DECnet (norvlicensed 
single-node operation is adequate) 

The MOVE_ PASSWORD utility permits a user 
to move a system generated password from one 
account to another across DECnet With this, users 
can have the same system generate password on 
several accounts, yet still obtain a new system gener¬ 
ated password for all these accounts whenever de¬ 
sired, without assistance from a system manager. 
Either a primary or secondary password can be moved 
from any account requiring passwords to be system 
generated, if the user knows the password to be moved 
and the password to be replaced. Certain other re¬ 
strictions are also enforced. Password expiration 
dates are not extended. 

The included DECnet remote server does not 
provide passwords or encryptions to accessing 
nodes, only limited information and status. 

The utility and remote node server each com 
municate only with nodes which are listed in special 
files. 

Restrictions: Source code patch (as described in 
documentation) needed for VMS releases otherthan 
4.2. (For mapping to a VMS copy of the password 
encryption routine). 

Documentation on magnetic media 

Media (Service Charge Code): 600’ Magnetic Tape 
(MA), Format: VMS/BACKUP, Blocked at 8192 


LIB-1 


LIB-2 


DECUS NO: VAX-153, Title: “DEP’ DECENC- Decrypted 
Encrypter, Version: VI .0, December 1 985 

Submitted by: Soft-Keyz, Cameron MO, Operating Sys¬ 
tem: VAX/VMS V4.1, 4.2 Source Language: VAX-11 
FORTRAN 

Abstract: “DEP’ permits a user to decrypt/encrypt any 
VMS file with a record length less than or equal to 8180 
bytes. The “DEP’ is best utilized in internal security. 

A minimum 1 0 character key must be provided for 
encryption and although there is no maximum number 
of characters which a key may have, it will be hashed 
into a 512 character key. 

The user may encrypt a file to as many levels as 
desired, that is; an encrypted file can be re-encrypted. 

The" DEP’ also allows the user to expand the input 
text with random garbage thrown into the output text. 
The ratio of expansion per encryption is from 31 bits in, 
32 bits out (adding 1 bit garbage), up to 1 bit in, 32 bits 
out(adding31 bits garbage per bit). Decryption(s) must 
proceed in the exact reverse order of the encryption(s). 

Keys may be entered from the keyboard with/ 
without echo or from a file. Mostfiletypes currently sup¬ 
ported by VMS can be used as a key as long as the 
record length is less than 8192 bytes. 

Release Notes are distributed with each order. 

Restrictions: Needs at least VMS 4.1. 

Documentation on magnetic media 

Media(Service Charge Code): 600’ MagneticTape(MA), 
Format: VAX/ANSI, Blocked at 2048 


DECUS NO. VAX-154, Title: Screen Management 
System Subroutines, Version: December 1985 

Submitted by: Kenneth Messer, Allied Electronics, 
Ft Worth TX, Operating System: VAX/VMS V4.2 re¬ 
quired, Source Language: VAX-11 BASIC 

Abstract This submission consists of a group of sub¬ 
routines written in VAX BASIC V2.3, comprising a 
system allowing the (relatively) simple usage of the 
new VAX Screen Management System under VMS 
version 4.2. Also, included is a demonstration pro¬ 
gram using it With this system, a programmer can 
create up to 10 virtual displays and manipulate them 
quite simply, by keeping track of the sequence num¬ 
ber of the intended virtual display (0 through 9) and 
passing that number as an argument in the subroutine 
call. Specific information about the routines, as well 
as argument layouts and more detailed explanations, 
are to be found in SMGDOC.MEM, which is included 
in the submission. 

Restrictions: Software is known to work satisfactorily, 
but as with any new system, unforseen bugs are sure 
to arise. 


Documentation on magnetic media 

Media (Service Charge Code): 600 Magnetic Tape 
(MA), Format VMS/BACKUP, Blocked at 8192 


DECUS NO: VAX-157, Title: Clinimetric Data Manage¬ 
ment Software for Interactive Data Entry, Version: V5.5, 
March 1 985 

Submitted by: Messrs. W. Dupont & W. Plummer, Van¬ 
derbilt, University, NashvilleTN, Operating System: VAX/ 
VMS V4.1, Source Language: MACRO-32, FORTRAN 
77 

Abstract: The CLINIMETRIC Data Management Sys- 
tem(CDMS) facilitates interactive data entry and editing 
by people without previous computer skills. The user 
first writes a simple program that defines the data dic¬ 
tionaries of the data files that are to be entered. This pro¬ 
gram is then compiled to create control files that enable 
the package’s utility programs to be customized to the 
user's needs. 

Data may then be entered, edited and reviewed 
using the interactive data entry utility. Prompting messages 
obtained from the data dictionaries guide the user through 
each data form. One or more data values may be entered 
in free format between prompting messages. This makes 
data entry and editing tasks easy to learn and perform. 
Entry errors can be detected and corrected immediately. 
Lists of remaining edit checks can be generated for 
subsequentverification and correction. Data points that 
are not entered are automatically assigned missing value 
codes. The user may alter the order of data entry to skip 
missing entries or change previously entered values. 

An indexed file structure allows rapid and con¬ 
venient access to any record in each file. Interactive 
inter-file edit checks can enforce consistency between 
files in a multi-file data base. Other features include 
interactive help messages, relational edit checks, date 
variables, record certification, and automatic case con¬ 
version. CDMS data files may be accessed as sequen¬ 
tial files with fixed data formats. Documentation files 
provide the column locatio and format of each variable 
in the file and summarize the data dictionary. A utility 
converts existing sequential files into a CDMS system. 

Release Notes distributed with each order. 

Documentation on magnetic media 

Media(Service Charge Code): User's Manual(EC),2400’ 
MagneticTape(PA), Format: VMS/BACKUP, Blocked at 
8192 


Abstract GDADL is an Ada-based Program Design 
Language. The GDADL processor analyzes Ada pro¬ 
grams (both executable Ada code and PDL pseudo¬ 
code) in order to produce documentation which describes 
the design at any stage of development. The GDADL 
processor consists of over25 software tools which pro¬ 
duce such reports as: 

• Pretty-print design and source code 

• Program unit invocation tree 

• Type cross reference report 

• Object cross reference report 

• Generic instantiation report 

• Data-dictionary 

• Areas of the design which are To Be Defined 
(TBD) 

Upto ten additional user-defined project manage¬ 
ment reports can be used to identify such items as: 

• Requirements traceability to the program units 

• Identification of areas which have been re¬ 
vised 

• Responsible designers, etc. 

The cycllomatic complexity of both the pseudo¬ 
code design and the executable Ada code is analyzed 
and reported for each program unit. 

The designer does not need to have access to an 
Ada compiler to use GDADL, or the GDADL processor. 
However, designs expressed in GDADL are fully com¬ 
pilable using any Ada compiler. 

Sources not included. Documentation available in hard¬ 
copy only. 

Media(Service Charge Code): User's Manual (ED), 600' 
Magnetic Tape (M A), Format: VAX/ANSI, Blocked at 
2048 


DECUS NO: VAX-159, Title: FONT2XX, Version: VI .0, 
October 1 985 

Submitted by: William Porteous, Operating System: VAX/ 
VMS V4.2 Source Language: VAX-1 1 FORTRAN 


DECUS NO: VAX-158, Title: GDADL- Ada-Based Design 
Language Processor Version: V2.2, November 1985 

Submitted by: Computer Systems Design, Claremont 
CA Operating System: VAX/VMS V4.1, Source Language: 
C, Memory Required: 51 2 K 


Abstract: FONT2XX is a program which helps one 
generate character sets for the Digital VT200 series of 
terminals. Instead of trying to determine the bit patterns 
associated with custom character sets, one uses an 
editor(any editor will do) to create the characters. From 
the data file containing the characters, FONT2XX will 
create an output file with all the escape sequences re¬ 
quired by the VT2XX terminal for character generation. 

Sample character sets are included which corres¬ 
pond to the Digital symbols set the Digital technical 
character set and the Apple Macintosh extended charac¬ 
ter set. 

Documentation on magnetic media 

Media(Service Charge Code): 600’ Magnetic Tape( MA), 
Format: VMS/BACKUP, Blocked at 8192 

DECUS NQ V-SP-48, Title: Best of PC-8088 Collec¬ 
tions 1 -8, Version: VI December 1985 

Submitted by: Glenn Everhart Ph.D, Operating Sys¬ 
tem: MS/DOS, CP/M Source Language: PASCAL, 
FORTRAN 77, FORTRAN IV, FOCAL C, BASIC, APL 
Software Required MS/DOS. CP/M 

Abstract This submission contains about 400 disks 
worth of utilities from the PC-SIG library for IBM PC 
and MS/DOS machines and from several bulletin 
boards. The files were transferred to VMS in KE RM IT 
filetype Binary mode and can be restored to PC s in 
the same way. 

VMS Kermit (and other Kermits) are NOT in this 
submission. 

Restrictions: Some programs need close replicas of 
IBM PC. 

Complete sources not included Documentation on 
magnetic media 

Media (Service Charge Code): 2400 Magnetic Tapes 
(PB). Format VMS/BACKUP. Blocked at 16384 
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REVISIONS TO LIBRARY PROGRAMS 


DECUS NO: Revision 20-1 83, Title: ANSIMT: A Utility to 
Transfer 7-Bit ASCII Files, Version: VI .02-2, December 
1985 

Submitted by: Jeffrey Blomberg, U.H. Computing Cen¬ 
ter, Honolulu, HI Operating System: TOPS-20 release 
5.1, Source Language: PASCAL Memory Required: 25 KW, 
Software Required: Rutger’s PASCAL version 14 Edit 
331 (or later) with the CM N D jsys interface developed by 
Charles Hedrick of Rutger’s University, only required for 
recompilation., Special Hardware Required: 800 BPI, 
1600 BPI or6250 BPI Tape Drive 

Abstract: ANSI MT is aTOPS-20 Tape utility whose func¬ 
tion is to easily transfer 7-bit ASCII files between disk 
storage and 9-track magnetic tape. ANSIMT supports 
fixed formatted tape files on 800/1600/6250 bpi ANSI 
standard labeled tapes and can also read from EBCDIC 
labeled tapes. Features include stripping trailing blanks 
while restoring from magtape, padding tabs while stor¬ 
ing to tape, and producing directory listings of the tape. 
ANSIMT uses thefull command recognition features of 
TOPS-20. A help file is included. 


Changes and Improvements: Removed the depen¬ 
dency on the Rutger’s Pascal Sharable Runtimes. 
ANSIMT.EXE and ANSIMT.HLP are all that is needed to 
run the utility. We are providing a complete copy of our 
submittal and supporting files. 

Restrictions: Must use Rutger’s PASCAL Version 14, 
Edit 331 with COM N D jsys interface to rebuild. Writes 
fixed format ANSI labeled tapes only, reads EBCDIC 
but can’t write EBCDIC; can read ANSI D-Format tapes. 

Documentation on magnetic media 

Media (Service Charge Code): 600’ Magnetic Tape (MA) 


DECUS PROGRAM LIBRARY CHANGES: 

DECUS NO: 11-816 TITLE: Update Suite PROGRAM 
STATUS: On hold DATE: 20 Feb 86 
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HOW TO SUBMIT TO A SPECIFIC SECTION OF THE NEWSLETTER 

The following is a listing of the Newsletter Editors with their addresses and phone numbers. All sub¬ 
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PERSONAL COMPUTER 

Caroline Mack 
9007 Mears Street 
Fairfax, VA 22031 
(703) 280-4404 
[Upload submissions to 
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(408) 988-2211 


DATATRIEVE 

Donald E. Stern, Jr. c/o 
Warner Lambert Company 
10 Webster Road 
Milford, Ct 06460 
(203) 783-0238 


EDUSIG 

Fred Bell 
Taft College 
29 Emmons Park Drive 
P.O. Box 1437 
Taft, CA 93268 
(805) 763-4282 


HMS 

William Walker 
Monsanto Research Corp. 
P.O. Box 32 A-152 
Miamisburg, OH 45342 
(513) 865-3557 


LANGUAGES & TOOLS 

Alan Folsom Jr. 

Fischer & Porter Company 
E. County Line Road 
Warminster, PA 18974 
(215)674-7154 


MUMPS 

Janet Berryman 
2405 N. Bush 
Santa Ana, CA 92706 
(714) 953-1025 


OFFICE AUTOMATION 

Margaret Drake 

Univ. of TX Health Science Ctr. 

7703 Floyd Curl Drive 

San Antonio, TX 78284 

(512) 691-6105 


RSTS 

Bill Hobbs 
ComManD. Inc. 

6535 E. 82nd St., Suite 102 
Indianapolis, IN 46250 
(317) 842-5320 


RT 

Bill Leroy 

The Software House, Inc. 
2964 Peachtree RDNW#320 
P.O. Box 52661 
Atlanta, GA 30355 
(404) 231-1484 


UNISIG 

William Toth 

Harvard-Smithsonian Ctr. for 
Astrophysics 
60 Garden Street P353 
Cambridge, MA02138 
(617) 495-7181 

Bruce Bergman 
UserWare International 
2235 Meyer Avenue 
Escondido, CA 92025-1 070 
(619) 741-8825 
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HOW 


SUBMITTING ARTICLES TO THE HMS SIG NEWSLETTER 


The purpose of the HMS SIG Newsletter is to serve as a forum 
to share information related to DEC hardware with the 

members of the SIG. As such, the existence of the 

newsletter is entirely dependent on your contributions. If 

you have an HHK item, a better or safer way to do something, 
product news, a tutorial article of general interest, etc., 
we are interested in publishing it in the newsletter. It is 
intended that the HMS SIG Newsletter be published at least 
four times a year. 

There are several ways to submit material for the 

newsletter: 

o The Hardware Submission Form in the back of the 

newsletter can be used for brief items (there is 

not enough room if you have a lot to say). 

o You can send me camera-ready hard-copy (this saves 
me a lot of typing). 

o I will accept submissions on floppys. I can handle 
RX50's or 8" diskettes (either density, single or 
double sided). I prefer RT-11 format, if possible, 
but I can probably handle RSX or VMS stuff somehow. 
I will return your diskette(s), of course. 

o Those of you that have access to DCS can send 

things to username WALKER. I check DCS daily. 

o I am also on CompuServe as "Bill Walker 71066,24". 

In any event, if you have anything to submit, send itl If 
it is a mess, but I can read it, I will get it in the 
newsletter somehow. Finally, if you have any question about 
submitting material, call me. My telephone number is listed 
below. 

Contributions can be sent to: 

HMS Editor William K. Walker 

DECUS OR Monsanto Research Corp. 

BP02 == P.0. Box 32 A-152 

249 Northboro Road Miamisburg, OH 45342 

Marlboro, MA 01752 (513) 865-3557 

If you need to get something to me quickly, send it to my 
work address. 
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DECUS 


OECUS SUBSCRIPTION SERVICE 

SIGs NEWSLETTERS 
U.S. CHAPTER MEMBERS ONLY 


As a member of DECUS U.S. Chapter, you are entitled to contribute and subscribe to the DECUS 
monthly publication, SIGs Newsletters. You also have the opportunity to subscribe to the Symposia 
Proceedings which are a compilation of the reports from various speakers at the U.S. National 
DECUS Symposia. 

• No Purchase Orders will be accepted. 

• The order form below must be used as an invoice. 

• All checks must be made payable to DECUS. 

• All orders MUST be paid in full. 

• No refunds will be made. 

• The address provided below will be used for all DECUS mailings; i.e. Membership, Subscription 
Service and Symposia. 

• SIGs Newsletters Price is for a one-year subscription beginning the month following receipt of 
payment. 


Name_DECUS Member No_ 

Company___ 

Address_ _ 


City_State_Zip 

Phone_ __ 


Subscription Service Offering 

SIGs Newsletters 
Fall ’85 Proceedings (FA5) 
Spring’86 Proceedings (SP6) 
Fall ’86 Proceedings (FA6) 
Spring’87 Proceedings (SP7) 


Qty. Unit Price Total 

_ $35.00 _ 

15.00 

_ 15.00 

_ 15.00 

_ 15.00 


TOTAL COST OF SUBSCRIPTION $_ 


□ MASTERCARD □ VISA □ DINERS CLUB/CARTE BLANCHE® 

_Exp. Date _ . .... ___ _ __ 

I understand that there will be no refunds even if I decide to cancel my subscription. 

Signature:_____ 

FOR DIGITAL EMPLOYEES ONLY FOR DECUS OFFICE ONLY 

Badge No._CC:_ _ Check No_ 

CC Mgr. Name_Bank No_ 

CC Mgr. Signature_Amounts_ 

Subscription Service, DECUS(BP02),21 9 Boston Post Road, Marlboro, MA01 752-1850,(61 7) 480- 
3418. 
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DECUS U.S.CHAPTER 
APPLICATION FOR MEMBERSHIP 


□ New Membership □ Update to current membership profile Current DECUS Member. #_ 

NOTE: PLEASE PRINT CLEARLY OR TYPE! 

PLEASE PROVIDE A COMPLETE MAILING ADDRESS. INCLUDE ZIP CODE IN ACCORDANCE WITH POSTAL 
REGULATIONS FOR YOUR LOCALITY. 

ARE YOU AN EMPLOYEE OF DIGITAL EQUIPMENT CORPORATION?□ YES □ NO 

Name:_ 

(first) (Middle Intial) (Last/Family Name) 

Company:_ 

Address : ____ 


City/Town: 


State: 


Zip: 


Telephone: Home 


Work ( ) 


HOW DIO YOU LEARN ABOUT DECUS? Please check applicable item. 


1 □ ANOTHER DECUS MEMBER 

2 □ SYMPOSIA 

8 □ DECUS CHAPTER OFFICE 
10 □ DIGITAL STORE 


4 □ DIGITAL SALES 

5 □ HARDWARE PACKAGE 

6 □ SOFTWARE PACKAGE 
12 □ ADVERTISING 


13 □ LOCAL USER GROUP 

14 □ SPECIAL INTEREST GROUP 
7 □ SOFTWARE DESPATCH 

(DIGITAL Newsletter) 


DO YOU WISH TO BE INCLUDED IN MAILINGS CONDUCTED BY DIGITAL (for Marketing purposes etc ?) 
TYPE OF DIGITAL HARDWARE USED: Please check those applicable to you. 


□ Permission 

□ Refusal 


20 □ DECMATE 

82 □ DECsystem-10 

83 □ DECSYSTEM-20 


52 □ LSI-11 
3 □ PDP-8 FAMILY 
50 □ PDP-11 FAMILY 


21 □ PROFESSIONAL 

22 □ RAINBOW 
54 □ VAX FAMILY 


5 □ WPS-8 
51 □ WPS-11 


MAJOR OPERATING SYSTEMS? LANGUAGES USED: Please check those applicable to you 


1 

□ 

ADA 

26 

□ 

CORAL-66 

47 

□ 

FOCAL 

67 

□ 

OS/8 

109 

□ 

RT-11 

2 

□ 

ALGOL 

28 

□ 

COS 

48 

□ 

FORTRAN 

68 

□ 

PASCAL 

97 

□ 

TECO 

5 

□ 

APL 

34 

□ 

DATATRIEVE 

51 

□ 

GAMMA 

72 

□ 

PL-11 

70 

□ 

TOPS-10 

7 

□ 

BASIC 

35 

□ 

DBMS 

110 

□ 

IAS 

92 

□ 

RPG 

71 

□ 

TO PS-20 

17 

□ 

BLISS 

38 

□ 

DECnet 

53 

□ 

IQL 

81 

□ 

RSTS/E 

104 

□ 

VMS 

19 

□ 

C 

43 

□ 

DIBOL 

58 

□ 

MACRO 

83 

□ 

RSX 

107 

□ 

WPS-8 

22 

□ 

COBOL 

45 

□ 

DOS-11 

65 

□ 

MUMPS 

91 

□ 

RMS 





HOW-5 







II 


TYPE OF BUSINESS (ENVIRONMENT)/COMPUTER APPLICATIONS 

Please check that which best describes your business/appiication 


21 

□ 

ACCOUNTANCY 

1 

□ 

EDUCATION/PRIMARY 

73 

□ 

NUMERICAL CONTROL 

7 

□ 

BANK 

2 

□ 

EDUCATION/SECONDARY 

68 

□ 

OEM-COMMERCIAL 

64 

□ 

BUSINESS/COMMERCIAL 

61 

□ 

EDUCATION-TECHNOLOGY 

78 

□ 

OEM-TECHNICAL 

74 

□ 

BUSINESS/INFORMATION SYSTEMS 

3 

□ 

EDUCATION/UNIVERSITY 

56 

□ 

PHYSICAL SCIENCES 

57 

□ 

CHEMISTRY 

67 

□ 

ENGINEERING 

20 

□ 

RESEARCH/DEVELOPMENT 

54 

□ 

CLINICAL LABORATORY 

65 

□ 

FINANCE/ACCOUNTING 

10 

□ 

RETAIL 

63 

□ 

COMPUTATION 

77 

□ 

GOVERNMENT 

76 

□ 

SOFTWARE DEVELOPMENT 

11 

□ 

CONSUMER ELECTRONICS 

75 

□ 

GRAPHICS 

53 

□ 

TELECOMMUNICATIONS 

18 

□ 

CONSULTANT 

4 

□ 

HOSPITAL 

19 

□ 

TELEPHONE/UTILITIES 

72 

□ 

DATA ACQUISITION 

62 

□ 

INDUSTRIAL 

51 

□ 

TIMESHARING 

52 

□ 

DATA COMMUNICATIONS 

55 

□ 

LABORATORY/SCIENTIFIC 

80 

□ 

TRAINING/INSTRUCTION 

13 

□ 

DATA PROCESSING SERVICES 

14 

□ 

LIBRARY 

66 

□ 

TYPESETTING/PUBLICATION 

71 

□ 

DATA REDUCTION 

58 

□ 

LIFE SCIENCES 




17 

□ 

DIGITAL EMPLOYEE-ENGINEERING 

70 

□ 

MANUFACTURING 




15 

□ 

DIGITAL EMPLOYEE-MARKETING 

79 

□ 

MARKETING 




16 

□ 

DIGITAL EMPLOYEE-SERVICE GROUP 

59 

□ 

MEDICAL RESEARCH 




60 

□ 

EDUCATIONAL ADMINISTRATION 

6 

□ 

MILITARY INSTALLATION 





SPECIAL INTEREST GROUP (SIGs) ENROLLMENT 

I wish to participate in the following DECUS U.S. Chapter Special Interest Groups. 


33 

□ 

APLSIG 

11 

□ 

HARDWARE AND MICRO 

36 

□ 

PERSONAL COMPUTER 

2 

□ 

COMMERCIAL 

35 

□ 

IAS 

18 

□ 

RSTS/E 



LANGUAGES 

31 

□ 

DAARC(LABS) 

17 

□ 

RSX 

6 

□ 

DATA MGMT.SYS. 

27 

□ 

LARGE SYSTEMS 

19 

□ 

RT-11 

5 

□ 

DATATRIEVE 

16 

□ 

LANG. AND TOOLS 

32 

□ 

SITE MGMT.&TRNG 

7 

□ 

BUSINESS APPL. 

14 

□ 

MUMPS 

21 

□ 

UNISIG 

8 

□ 

EDUSIG 

15 

□ 

NETWORKS 

26 

□ 

VAX SYSTEMS 

10 

□ 

GRAPHICS APPL 

34 

□ 

OFFICE AUTOMATION 





JOB TITLE/POSITION - Please check: 


1 

□ 

CORPORATE STAFF 

101 

□ 

CORPORATE DIRECTOR OF DP/MIS 

2 

□ 

DIVISION OR DEPARTMENT STAFF 

102 

□ 

ADMINISTRATIVE ASSISTANT 

3 

□ 

SYSTEMS ANALYSIS 

103 

□ 

TECHNICAL ASSISTANT 

4 

□ 

APPLICATIONS PROGRAMMING 

104 

□ 

SERVICES COORDINATOR 

5 

□ 

SYSTEMS ANALYSIS/PROGRAMMING 

105 

□ 

MANAGER 

6 

□ 

OPERATING SYSTEM PROGRAMMING 

106 

□ 

ANALYST 

7 

□ 

DATABASE ADMINISTRATION 

107 

□ 

PROGRAMMER 

8 

□ 

DATA COMMUNICATIONS/TELECOMMUNICATIONS 

108 

□ 

DATABASE MANAGER 

9 

□ 

COMPUTER OPERATIONS 

109 

□ 

DATABASE ADMINISTRATOR 

10 

□ 

PRODUCTION CONTROL 

110 

□ 

MANAGER OF DP OPERATIONS 


CITIZEN OF UNITED STATES OF AMERICA? □ Yes □ No Country:. 
Signature:_ Date: _ 


Forward To: 

DECUS U.S. CHAPTER, MEMBERSHIP PROCESSING GROUP 
219 BOSTON POST ROAD 
MARLBORO, MA01752, USA 
PHONE: (617) 480-3418 
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PAGESWAPPER - April 1986 - Volume 7 Number 9 

INPUT/OUTPUT Submission Form 


INPUT/OUTPUT Submission Form 


A SIG Information Interchange 
Please reprint in the next issue of the Pageswapper 

If this is a reply to a previous I/O, which number? _ 

Caption: _ 

Message: _ 


Contact: 

Name _ 

Address 


Telephone _ 

Signature _ Date _ 

Mail this form to: Larry Kilgallen, PAGESWAPPER Editor 
Box 81, MIT Station, Cambridge, MA 02139-0901, USA 





PAGESWAPPER - April 1986 - Volume 7 Number 9 
INPUT/OUTPUT Submission Form 


Tear out or photocopy reverse to submit an I/O item 


Larry Kilgallen, PAGESWAPPER Editor 
Box 81, MIT Station 
Cambridge, MA 02139-0901 
USA 
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System Improvement Request Submission Form 


System Improvement Request Submission Form 

Page 1 of _ 


Submittor: Firm: 

Address: Phone: 


How to write an SIR: 

Describe the capability you would like to see available on VAX 
systems. Be as specific as possible. Please don't assume we 
know how it's done on the XYZ system. Justify why the capability 
would be useful and give an example of its use. If you wish, 
suggest a possible implementation of your request. 


Abstract (Please limit to four lines): 


Description and examples 


(use additional pages if required) 


OU-3 


PAGESWAPPER - April 1986 - Volume 7 Number 9 
System Improvement Request Submission Form 


Tear out or photocopy reverse to submit an SIR 


Gary L. Grebus 

Battelle Columbus Division 

Room 11-6011 

505 King Avenue 

Columbus, Ohio 43201-2693 

USA 
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VAX Systems SIG Spring 1986 SIR Ballot 


VAX Systems SIG Spring 1986 SIR Ballot 


DECUS membership number _ (six digits) 

Our site uses the following VAX models (check all that apply) 

8600 11/782 11/780,11/785 11/750 

11/730,11/725 _ MicroVAX _ 


We use VAX's in the following applications (Check all that apply) 

Business EDP _ Software Development _ 

Education _ Computer Science Research _ 

Data Acquisition/Control_ CAD/CAM _ 

Service Bureau _ Hardware Development _ 

Scientific/Engineering _ Office Automation _ 

Telecommunications _ 

Other _ 

I support the following as the most important System Improvement 
Requests. (List from zero to fifteen SIR's): 

SIR Number: 


I oppose the following SIR'S as detrimental. (List from zero to 
five SIR's): 

SIR Number: 


Mail to: 

Gary L. Grebus 
Battelle Columbus Division 
Room 11-6011 
505 King Avenue 
Columbus, OH 43201 

To be counted, you ballot must be received by April 1. 
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PAGESWAPPER - April 1986 - Volume 7 Number 9 
VAX Systems SIG Spring 1986 SIR Ballot 


Tear out or photocopy reverse to vote on SIRs 


Gary L. Grebus 

Battelle Columbus Division 

Room 11-6011 

505 King Avenue 

Columbus, Ohio 43201-2693 

USA 



OFFICE AUTOMATION SIG 

SYSTEM IMPROVEMENT REQUEST SUBMISSION FORM 


1 of 


Name _ Address 

Firm _ _ 

Telephone _ _ 


INSTRUCTIONS: System Improvement Requests (SIR) can be either hardware of software; 
please check the category addressed by this SIR. Under ABSTRACT, give a brief 
definition of the capability you would like. In the DESCRIPTION section, give a 
detailed description and examples of what you want. Be specific; don’t assume that 
we know how other products function. Justify the usefulness of the capability and 
give an example of its use. 


HARDWARE IMPROVEMENT 

DECmate_ 

PRO-Series_ 

Rainbow _ 

Other 


SOFTWARE IMPROVEMENT 

ALL-IN-1 _ WPS _ 

CP/M (DECmate)_ P/OS_ 

CP/M (Rainbow) _ MS-DOS _ 

Other 


ABSTRACT 


DESCRIPTION 
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E. Catherine Ditamore 
ARA Services 
Corp MIS 

Independence Square West 
Philadelphia, Pa. 19106 
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DATAGRAMS are short messages, comments, requests, or answers 
that are published In NETwords. Please Till in the sections below 
and send the DATAGRAM to: 

Vickie Hancock 
NETWords Editor 
2510 Limestone Ln. 

Garland, Tx. 75040 


Title:_ 

Message: 


Your Name: _ 

Address: _ 

Telephone: _ 

If this is a reply to a previous DATAGRAM, what 9 7 _ 

Signature:_Date:_ 





Place | 
Stamp I 
Here : 


Vickie Hancock 
NETWords Editor 
2510 Limestone Ln. 
Garland, Tx. 75040 


Fold Here 
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Printed in the U.S.A. 


"The Following are Trademarks of Digital Equipment Corporation” 
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DEC 

DECnet 

DECmate 

DECsystem-10 

DECSYSTEM-20 

DECUS 

DECwriter 

DIBOL 


Digital logo 
EduSystem 
IAS 

MASSBUS 

PDP 

PDT 

P/OS 

Professional 

Rainbow 


RSTS 

RSX 

RT 

UNIBUS 

VAX 

VMS 

VT 

Work Processor 


Copyright ®DECUS and Digital Equipment Corporation 1986 
All Rights Reserved 


The information in this document is subject to change without notice and should not 
be construed as a commitment by Digital Equipment Corporation or DECUS. Digital 
Equipment Corporation and DECUS assume no responsibility for any errors that 
may appear in this document. 

POLICY NOTICE TO ALL ATTENDEES OR CONTRIBUTORS “DECUS PRESEN¬ 
TATIONS, PUBLICATIONS, PROGRAMS, OR ANY OTHER PRODUCT WILL NOT 
CONTAIN TECHNICAL DATA/INFORMATION THAT IS PROPRIETARY, CLASSI¬ 
FIED UNDER U.S. GOVERNED BY THE U.S. DEPARTMENT OF STATE’S INTER¬ 
NATIONAL TRAFFIC IN ARMS REGULATIONS (ITAR).” 

DECUS and Digital Equipment Corporation make no representation that in the 
interconnection of products in the manner described herein will not infringe on any 
existing or future patent rights nor do the descriptions contained herein imply the 
granting of licenses to utilize any software so described or to make, use or sell 
equipment constructed in accordance with these descriptions. 

It is assumed that all articles submitted to the editor of this newsletter are with the 
authors’ permission to publish in any DECUS publication. The articles are the 
responsibility of the authors and, therefore, DECUS, Digital Equipment Corporation, 
and the editor assume no responsibility of liability for articles or information 
appearing in the document. The views herein expressed are those of the authors and 
do not necessarily express the views of DECUS or Digital Equipment Corporation. 

Ada is a trademark of the U.S. Government, XEROX is a trademark of Xerox 
Corporation, IB M, PROFFS are trademarks of International Business Machines 
Corporation, UNIX is a trademark of AT&T Bell Laboratories, CP/M, PIVI aretademarks 
of Digital Research, Inc., MS-DOS is a trademark of Microsoft Corporation, TSX- 
PLUS is a trademark of S&H Computer Systems, Inc. 
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STATUS CHANGE 

Please notify us immediately to guarantee 
continuing receipt of DECUS literature. Allow 
up to six weeks for change to take effect. 

( ) Change of Address 

( ) Please Delete My Membership Record 

(I Do Not Wish To Remain A Member) 

DECUS Membership No:__ 

Name:_ 

Company:_ 

Address:_ 


State/Country:_ 

Zip/Postal Code:_ 

Mail to: DECUS - Attn: Subscription Service 
219 Boston Post Road, BP02 
Marlboro, Massachusetts 01752-185 

USA 
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